Вторник, 26.09.2017, 17:33
Приветствую Вас Гость | RSS
Главная | Каталог статей | Регистрация | Вход
Форма входа
Логин:
Пароль:
Поиск

Меню сайта

Категории раздела
Общие статьи [18]
Переводные статьи [6]
Примеры [8]
Эмуляторы [2]
Linux [3]
Презентации по IBM DS [6]
О.Ю.Еремин. Материалы по технологиям хранения и восстановления информации.

Наш опрос
О регистрации на сайте с помощью соцсетей.
Всего ответов: 12

Метки
EGL ODM бизнес правила программирование SOA arcati блоги журналы Каталог мейнфреймы журнал z/os Freeware VM bigdata nosql MVS OS zOS SLES zLinux мейнфрейм Хабрахабр 50лет документы хранилище Java EE liberty WebSphere history сообщение Форум DFSORT Hercules VSAM отчётность Linux Analytics Accelerator Netezza IMS IBM IDC продажа CHKPT GSam XRST гипервизор KVM Shutdown #hollywar mainframe Вакансии Санкт-Петербург пример Assembler LHI vs XR instruction to clear GPR z Seies CPU performance семинар впечатление доступность ЦБ цены аутсорсинг BMC CMS ZVM санкции Rockwell история z13 мобильность DB2 Java Coupling Facility Parallel Sysplex WebSphere AS MVT ОС ЕС ссср Tape VTL Вакансия БЛОГ Линукс Новое статьи Люксофт Польша Работа

Статистика

Главная » Статьи » Мейнфреймы » Общие статьи


Подходы к созданию программно-техническим комплексов министерств и ведомств РФ. Часть 4.
Продолжение. Часть 1. Часть 2. Часть 3. Часть 4.

6 Предложение.

1. Выработать корпоративную стратегию развития, для определения способов консолидации и централизации.

2. Если централизация и консолидация будет предполагаться на основе регионов и/или департаментов, целесообразно использовать System P, базу данных DB2, для критической бизнес-логики TXSeries (CICS Family), для остальной WebSphere Application Server.

3. Для эффективного использования всех ресурсов и обеспечения наивысшего уровня качества предоставляемого сервиса ИТ услуг целесообразно применять System Z с использованием z/OS с максимальной степенью консолидации разных задач и централизации однотипных задач.

4. На переходном этапе к полной централизации целесообразно применять промежуточную консолидацию разных систем в System Z под управлением z/VM.

5. С целью максимальной утилизации возможностей, предоставляемых System Z, для обеспечения хранения и обработки критически важных данных в OLTP системах целесообразно применять IMS как в качестве архитектурного слоя хранения данных, так и в качестве слоя исполнения бизнес-логики по обработке данных.

6. Для реализации функций хранилища данных, OLAP систем, систем поддержки принятия решения, а также второстепенных по значению OLTP систем, не столь критичных к времени и качеству исполнения, уровням изоляции, целесообразно применять DB2, с аналитическими пакетами.

7. Для реализации и исполнения общей бизнес-логики целесообразно применять WebSphere Application Server, для построения и исполнения композитных бизнес-процессов — Process Server.

8. Для обеспечения отказоустойчивости и предотвращения недоступности систем целесообразно использования технологии Parallel Sysplex.

9. Для обеспечения катастрофоустойчивости целесообразно применения технологии GDPS — географически распределённого кластера.

10. Для обеспечения оптимальной загрузки System Z, уменьшения количества систем, и уменьшения затрат на интеграцию, целесообразно переносить на z/OS все доступные системы, добиваясь наилучшее соотношения между затратами на обслуживание систем, и количеством исполняемой работы.

11. Для снижения расходов и времени на программирования бизнес-логики целесообразно применять предлагаемые IBM высокоуровневые инструменты, такие как Rational Developer for System Z, язык EGL, инструменты управления, такие как IMS Explorer, средства организации и обеспечения жизненного цикла программного обеспечения.

7 Аппаратная реализация.

7.1 Переключение контекста в Z и других платформах.

При использовании виртуальной памяти особое значение имеют накладные расходы на переключение контекста адресного пространства. При этом виртуальную память делят на страницы относительно небольшого размера, например, в 4К. Обычно основой контекста являются две таблицы — таблица страниц, где хранится информация по расположению в реальной памяти виртуальных страниц, и таблица сегментов, более крупных фрагментов памяти, обычно объединяющих по 16–64 страниц. Скорость переключения контекста определяется тем, насколько быстро осуществляется загрузка в управляющие структуры процессора ссылок на таблицы страниц и сегментов того адресного пространства, которое должно стать активным. На других платформах это делается только для одного адресного пространства, и львиная доля работы осуществляется программно, так как единственная функция, возложенная на оборудование (в частности, на блок управления памяти MMU) при реализации виртуальной памяти состоит в трансляции адресов. На System Z уже начиная с архитектуры XA (это 1980-е годы) было 2 управляющих регистра, ссылающихся на отдельные наборы таблиц и сегментов, что позволяло без переключения контекста работать с двумя адресными пространствами. При этом переключение адресного пространства осуществлялось только сменой содержимого только управляющего регистра. В современной z/Architecture доступно 16 пар регистров доступа и управляющих, позволяющих одновременно, без переключения контекста процессора, выполнять 16 адресных пространств.

8 Программная реализация.

8.1 Циклы в разработке систем с использованием РСУБД.

1. Составление первоначальной структуры данных в РСУБД, составление запросов к данным для реализации бизнес-функций.

2. Эксплуатация и развитие системы, связанные с ростом количества обрабатываемых данных и количества обслуживаемых пользователей.

3. Появление неудовлетворительных по времени исполнения запросов, связанных с неоптимальными программами доступа к данным, генерируемыми оптимизатором.

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

5. Изменение в результате исследования:

• запросов на доступ к данным;

• структуры данных, к которым осуществляется доступ;

• поведение оптимизатора, применением к нему специальных инструкций;

• любому сочетанию предыдущих пунктов или всех вместе.

6. Изменение программ, использующих запросы доступа к данным, проведение циклов тестирования и сдачи в эксплуатацию.

7. Возвращаемся к пункту 2.

8.2 Накладные расходы РСУБД при обработке данных.

В основе реляционной модели данных, применяемых в РСУБД, лежит принцип объединения таблиц, в которых хранятся данные. Объединение множеств данных из таблиц происходит на основе сравнения значений ключевых полей разных таблиц, по одному из алгоритмов, выбранных оптимизатором. На выполнение задач сравнения затрачивается некоторая вычислительная мощность сервера, которой в большинстве случаев можно пренебречь. И какой бы алгоритм не был выбран оптимизатором из поддерживаемых конкретной РСУБД, в его основе всегда лежит операция сравнения значений ключевых полей таблиц, учавствующих в объединении. И с увеличением количества объеденяемых таблиц накладные затраты возрастают непропорционально быстро. По опыту IBM, при объеденении более пяти таблиц накладные расходы на операцию объеденения могут быть недопустимо велики по сравнению с остальными затратами на выволнения запроса. При невнимании программиста запросов на доступ к данным, при отсутствии изучения планов запросов на доступ к данным, возможно возникновение ситуаций, когда при необходимости вернуть небольшое количество данных, в виде десятка строк, происходит выбор из базы множества записей, с излишней затратой ввода-вывода, и последующим объединением таблиц, что приводит к операциям умножения больших множеств в памяти. При совпадении нескольких таких запросов по времени вполне возможно исчерпание доступной оперативной памяти и использование дисковой памяти. Всё это приводит к чрезмерному использованию вычислительной мощности и подсистемы ввода-вывода сервера, и как результат — к низкой производительности системы. В текущей ситуации на рынке со специалистами, описанной в пункте , такие запросы на доступ к данным стали скорее правилом, чем исключением.

8.3 Аналитики о IMS.

InformationWeek.

IMS still retains one advantage: the speed of «hard-wired» simplicity. That gives it the benefit of moving clearly defined transactions at a rate of 22,000 per second, a rate relational systems can’t match.

IMS has been periodically upgraded because some of IBM’s largest customers continue to depend on it. Last year, the company brought out IMS 10 with better XML handling capabilities and the ability to execute XQuery-based queries to retrieve small amounts of specific XML data. XML forms are constructed in a hierarchical way that lends their data to being stored in a hierarchical database.

EbizQ.

With more than 95% of Fortune 1000 companies using IMS, and more than 200 Million IMS users per day, integration of IMS services as part of modern Service Oriented Architectures has already been embraced by hundreds of IMS clients. IMS 11 will also continue to raise the bar for availability and performance while reducing the resources needed to manage the system.

Network Computing.

«IMS Transaction Manager and Database Manager are our most reliable front-end systems for our highest critical applications. I am excited to hear about the upcoming new features and functions on IMS 11. This shows IBM’s commitment to a long (another 40 years) and successful future for IMS,» added Manuel Gomez, DBA Manager, Confederacion Espanola de Cajas de Ahorros (CECA), which represents 46 Spanish Savings Banks and provide services to 96.3% of the population across the entire nation.

Stephen Swoyer, Enterprise Systems, 11/06/2007.

«Pre-relational databases don’t die, nor do they fade away.» «While industry watchers such as Gartner Inc. once encouraged customers to think about transitioning away from pre-relational DMBs’s, they’re now backtracking. In a recent report, Feinberg said organizations should also do a thorough cost/benefit analysis before embarking on any such migration…the risks and additional costs entailed by migrating away from a pre-relational DBMS outstrip the costs.» «Odd though it may sound, there is no reason for IBM not to continue to refresh IMS with the latest technologies, to fit its users for integration into SOA and event-driven architectures of the future.»

Wayne Kernochan, Illuminata Perspectives, 10/19/2007.

«An ongoing I/T fear is that IMS experts will become thin. I believe that these fears are entirely overblown. One of the nicest features of IMS is its simplicity. Unlike object-oriented programming, IMS requires relatively little training for programming or administration. Big Blue has ample opportunity to keep on keeping on as far as IMS is concerned…» «Time and again, enterprises have found that migrating from an existing database to an enterprise-standard one involves extraordinary time, effort, and risk. Migrating may involve a multi-year rewrite of dependent business-critical applications, somehow without affecting the IT organization’s imperative to «keep the business running». Small wonder that IMS is one of the «tough nuts to crack» of today’s legacy modernization.»

Charles King, Principal analyst at Pund-IT.

«The new version of IMS is a great example of one of the things IBM does best: leverage its deep technical expertise to develop and deliver solutions for customers’ fundamental business challenges. In most large enterprises, heterogeneous I.T. infra-structures are the rule, not the exception.»

Curt Monash, database analyst.

« IMS is one of the fine things to stick with.»

8.4 Применение IMS в финасовом учёте.

В области финансового учёта с 1452 года и момента фиксации метода двойной записи в математическом труде Лука Пачоли, принципиальных изменений не произошло вплоть до нашего времени, и не предвидится даже в отдалённом будущем. Всё также существуют понятия счёт, баланс счёта, и операция проводки, как уменьшение баланса одного счёта и увеличение баланса другого, с соответствующими записями. И не важно, реализовано это в книге из пергамента, или в современном компьютере — набор базовых объектов и операций неизменен. Один раз реализованные базовые структуры данных и операции в IMS позволяют строить поверх них банковские, страховые, и любые другие продукты любой сложности с любой требуемой частотой. Дополнительным подтверждением этому могут служить множествo финансово-учётных систем, реализованных 40 лет назад на IMS, и на основе которых множество организаций, банков и страховых компаний, предлагают потребителям вновь создаваемые разнообразные продукты.

8.5 Изменение структуры в РСУБД.

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

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

8.6 Извлечение одних и тех же данных из РСУБД структуры и IMS структуры.

Рассмотрим простую структуру данных, информация о человеке, и информацию о его адресах, которых может быть несколько. Допустим, информация о человеке будет три поля — фамилия, имя, отчество — по 20 байт, информация о адресе — индекс 6 байт, населённый пункт 20 байт, улица 20 байт, дом 3 байта, квартира 3 байта. В РСУБД данная структура может быть представлена в виде двух таблиц, таблица ФИО и таблица адресов, при чём таблица адресов будет содержать ключ из таблицы ФИО. В IMS эта структура может быть представлена в виде иерархии из двух сегментов, в котором ФИО является родительским, адрес дочерним. Пусть у нас есть две записи в таблице ФИО и каждой из них соответствует две записи в таблице адресов.

8.6.1 Последовательность извлечения данных в РСУБД.

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

2. Оптимизатор строит план выполнения запроса, выбирая один из методов объединения таблиц, пусть это будет наиболее распространённый метод вложенных циклов.

• Берётся первая строка из таблицы ФИО, и производится сравнение ключевого поля записи с аналогичным ключевым полем первой записи таблицы адреса (скорее всего в реальной системе будет сравнение с ключевым полем индекса, построенном на таблице адреса, но суть от этого не меняется, сравнение будет выполнено, просто появляется дополнительная сущность — индекс — и дополнительные операции ввода-вывода), если поля не совпадают, строка пропускается, если совпадают — происходит формирование строки результирующего набора записей.

• Берётся следующая строка из таблицы ФИО, и производится сравнение, как в предыдущем пункте.

• После прохода всех строк таблицы ФИО результат возвращается программе-клиенту в табличном виде.

ИвановИванИванович123456МоскваТверская3010
ИвановИванИванович654321МоскваДолгоруковская1030
ПетровПётрПетрович123456МоскваТверская3022
ПетровПётрПетрович654321МоскваДолгоруковская1040

3. Программа-клиент выполняет вызов Fetch, и получает первую строку результирующего набора записей.

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

5. При выполнении пятого вызова Fetch программа-клиент получит статус возврата, указывающий на отсутствие записей в результирующем наборе.

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

8.6.2 Последовательность извлечения данных из IMS.

1. Выполнение запроса, в котором указывается типы сегментов, которые необходимо вернуть — ФИО и адреса — и указывается тип операции — «Вернуть первый уникальный сегмент». После выполнения запроса в памяти программы-клиента находится первый сегмент ФИО в виде одной записи:

ИвановИванИванович

2. Выполнение запроса «Вернуть дочерний сегмент текущего родителя». Переход к дочернему сегменту выполняется IMS по ссылке, находящейся в префиксе найденного в предыдущем пункте сегмента. После выполнения запроса в памяти программы-клиента находится первый сегмент адреса в виде одной записи:

123456МоскваТверская3010

3. Повторение предыдущего запроса до получения всех сегментов адреса текущего человека, в данном случаев памяти программы будет находится второй сегмент адреса в виде одной записи:

654321МоскваДолгоруковская1030

Переход между дочерними сегментами осуществляется по ссылкам, находящимся в префиксах сегментов, найденных IMS при выполнении предыдущих вызовов.

4. При последующей попытке выполнения предыдущего запроса программа-клиент получит код возврата, означающий отсутствие искомого сегмента, после чего выполнит запрос «Вернуть следующий сегмент» с указанием параметров поиска из пункта . После выполнения запроса в памяти программы-клиента будет находится второй сегмент ФИО в виде одной записи:

ПетровПётрПетрович

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

123456МоскваТверская3022

и

654321МоскваДолгоруковская1040

6. При последующей попытке выполнить запрос из пункта программа-клиент получит статус возврата, означающий отсутствие искомого клиента.

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


Категория: Общие статьи | Добавил: akost (10.12.2010) | Автор: Власов Григорий
Просмотров: 1312 | Комментарии: 30


Всего комментариев: 30
1  
6. Для реализации функций хранилища данных, OLAP систем, систем поддержки принятия решения, а также второстепенных по значению OLTP систем, не столь критичных к времени и качеству исполнения, уровням изоляции, целесообразно применять DB2, с аналитическими пакетами.

- да, уж... наблюдая процесс построения ХД на DB2/zOS, думаю, что МежДелМаШ'у ещё есть над чем поработать более интенсивно... sad


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

3  
Да

4  
И дело не в разгильдяйстве IBM - wink

5  
таки да, оно (разгильдяйство) - есть. но не оно тут определяет!

6  
Александр, здравствуйте. Освежил память чтением статьи Григория. Любопытно было перечитать ее спустя год, после написания, не со всем согласен в ней,однако если можно было бы попросить Григория выложить приложение к данному документу, был бы весьма благодарен!

7  
А какое приложение имеется в виду?

8  
Мне показалось, что документ был написан для руководства, соответственно содержал минимум технической информации (и только в разделе 7-8). В самом документе есть намеки на более полное техническое освещение основных постулатов данного документа в неком мифическом Приложении. Если это Приложение реально существует (и им не является инфо-разделы 7-8 данного документа), то хотелось бы с ним, тоже, ознакомиться.

9  
Я думаю, что скорее всего дополнительные материалы к данному документу не появятся. Мне так кажется. Потому что технические подробности могут быть уже частью проекта и не для выкладывания на общедоступный сайт.
Вы можете Григорию (ggv) настучать личное сообщение. Но вроде бы он уже и так отдал все, что можно.

10  
Жили-были давным давно два известных талмудиста, друга, которые постоянно спорили друг с другом (оппонировали, это у них основной способ обучения).
И вот один из них умер.
А другой продолжает обучение со своими учениками.
И вот он высказывает мысль, а ученики вокруг:
- да, точно, так и есть, смотри, какой учитель гениальный!
Учитель погрустнел, чуть не заплакал.
- Что такое, ребе?
- Мой покойный друг привёл бы на это моё высказывание 28 возражений, зачем мне ваше согласие?!

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

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

По поводу построения корпоративного хранилища на DB2 z/OS - не знаю, за какой проект речь, но если за тот, за который я думаю, то изначально там и не хранилище вовсе было нужно. Если исходить из предъявляемых требований, как то иметь возможность в реальном времени откатить транзакцию... ТО позвольте, при чём здесь хранилище?
Есть действительно хороших инструментов, включая Netteza, или как там её, подключаемая к мэйнфрейму в качестве акселератора тяжёлых аналитических запросов, есть модели данных по отраслям, есть много чего - и есть конкретный бардак в конкретном проекте, это разные вещи.
Так что на реляционных базах таки можно строить хранилища. Особенно если честно самому себе ответить, что это такое, хранилище, для чего оно мине таки надо, как я его собираюсь использовать, и так далее, а если просто для того, чтобы не разогнали департамент так как ему нечем заняться....

14  
+100500 biggrin IW прекрасно строятся на реляционной СУБД, если ответить на поставленые в посте #10 вопросы (для чего... и как...) и правильно спроектировать процесс E-T-L. Иначе получится никакое не хранилище, а свалка, из которой не только аналитику, но и вообще что-либо полезное извлечь нельзя surprised

15  
Вы призвали "не соглашаться с Вами", - открываю свой список "несогласок" с общего вопроса: С чем связано, достаточно популярное на данном ресурсе, "игнорирование" VM и "излишний" пиар OS/390? OS -старее, сложнее, с большими издержками при конфигурации, труднее в поддержке, более требовательна к уровню специалистов,и т.д., но якобы "быстрее", надежнее и с сертификатами у нее дела обстоят лучше, и, главное, - ПОПУЛЯРНЕЕ в новых проектах. Про "быстрее", даже обсуждать не хочу, мы не в 90-х! Надежнее-это как посмотреть,а EAL5 для России это скорее реклама. Так в чем же дело? На чем покоится "такая любовь к OS" при реализации новых проектов?

16  
Да! Закономерный вопрос! Почему игнорируют VM?
Эмм.....Может потому, что сам IBM его игнорирует? Может, есть транзакционные системы, вроде CICS, под VM? Или горбыль типа GCS не дожил до времени ESA-архитектуры, хотя уже с XA можно было реализовать вменяемые средства работы "память-память" между виртуальными машинами на основе адресных регистров, а не мапить в лоб общий кусок памяти или мучиться с IUCV? А файловая система CMS, которая просто песня? А позиционирование VM от IBM как "навороченного гипервизора", а не самоценной системы? А отдельные деньги в VM за полноценный планировщик, средства мониторинга и пакетный монитор?....
IBM сделал все и даже больше, чтобы зарыть VM, и то, что VM жив, не заслуга IBM, а заслуга его заказчиков. Так что даже с моей любовью к VM я начинал общение с заказчиками имея на руках 2 списка - продукты IBM для VM и продукты для OS, и это, увы, были очень разные по длине списки.

17  
Бог с этими транзакциями, под VM или на LPARе - zOS можно с транзакционными пакетами поставить и доп.деньги за планировщик, тоже, можно отвалить, т.к. на "общем фоне" это потеряется. У IBM мало приложений для VM, а на "стороне" их тоже нет??? Или никто не ищет их? В наше время мы искали системные и прикладные приложения под VM по всей Москве, а также, в Минске и в Киеве и находили (спасибо спецслужбам СССР за "расторопность"). Сейчас другое время и возможности шире (или нет?).
С адресацией Вы правы, но так, тоже, не может вечно продолжаться, хотя уже почти 30 лет "воз и ныне там"?
Мне лично очень нравится VM, именно под VM было бы удобно развивать новые проекты. Интересно, что думают об этом другие форумчане?

18  
я думаю здесь стандартная подмена удобства и наличия знаний. Людям свойственно хвалить то, что они знают лучше. А то я знаю человека который готов и z/VM и z/OS заменить "удобным" линуксом. Потому что он ему очень нравится...

19  
Ну на самом деле VM и вправду неплохая система. Я уже несколько раз начинал писать свой "плач по VM", но не заканчивал, получалась статья без концепции. Лейтмотив ее был прост - передовая для своего времени система, но в развитии и продаже плохо позиционированная, почему и утратила преимущества.
На сегодняшний день технически система уже, увы, неконкурентноспособна (за исключением виртуализации). CMS уже лет 10 принципиально не развивается в концепциях. Мне жалко и больно от этого, я любил эту систему и работал промышленно больше 20 лет(((((.

20  
Кто же спорит. Система репрессивная за потенциальный канибализм. Мы тут сами не знаем что еще отрезать у VMAXe чтобы он покрывал mid и не лез в high storage где более дорогой VMAX. И как раз заказчики нехорошие заставляют таки возвращать\добавлять фичи.

21  
Осенью вышла новая версия VM - там только "fixs"? На рынке разве нет "сторонних" приложений под VM? Мне трудно поверить, что VM "так сдал", поэтому хотел проконсультироваться с профи, т.е. с Вами. У меня отнюдь не праздный интерес к MF. Хотели задействовать его в новом проекте вместе с Линуксом и OS...

23  
VM не то, чтобы сдал. VM не развивался в части концепции, позиционирования и разработанных под ним систем. И это правда ужасно.
VM давал прирост по сравнению с MVT или OS/SV, он дружественнее по интерфейсу (нет JCL) и все такое. Но это все в прошлом - никто из конечных пользователей или программистов не сидит уже в CMS или ISP/PDF или в CICS или вообще в PRIMUS. Все сидят на своей ПЭВМ и разрабатывают клиен-серверно. У нас полсотни программистов, и ни один не знает и никогда не видел JCL)))), его видят только три администратора, и только один пишет на нем задания, а остальные двое - запускают и корректируют в своей части (ну там диск указать, либо размер НД).
А вот как серверная ОС VM слил все бесповоротно. Теперь это на 90% приличный гипервизор.

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

25  
Да мы завсегда за кружкой чая готовы посидеть, тут вопросов особых нет. А там и народ может подтянуться.
Что касается того, как на перспективы VM повлияет Линукс - то мне кажется, что Линуксу от VM нужны только гипервизорные возможности, то есть возможности разделять имеющееся оборудования и эмулировать недостающее. Ну и еще, может, оптимизировать работу с оборудованием в части более эффективных каналок и подобного. Все. То есть ничего интересного в VM благодаря Линукс не появится, я так думаю.

26  
Супер! Готовлюсь, заказываю, заранее оповещаю. Надеюсь вариант вечером в центре города - проходит?

27  
Да, вечером, после 18, в центре, вполне подходит. Главное, знать дату хотя бы дня за два, а то всякое вечером у меня бывает.

28  
Приветствую Александр, планы на встречу в силе, оптимизм меня "подвел" по февралю,- поэтому март. Заранее дам знать. До встречи!

29  
Написал Вам в личку контакты. Подтверждаю готовность.

22  
Я бы не стал бы так иронизировать в части Линукса, кто знает как будет дальше, а то что эффективность программистов и системщиков повысилась при переходе с VS2 на VM было заметно "невооруженным взглядом".
То, что касается моих личных пристрастий, то раньше в OS меня сильно раздражал JCL, из-за него у меня был "зуб" на OS в целом.

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

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

12  
Только на прошлой неделе, беседуем по поводу "срочно подайте нам репликацию!"
Выясняю - зачем и откуда-куда будем реплицировать.
речь о региональных системах, то есть одна и та же система установлена 82 раза в каждом субъекте федерации.
Оказывается, одна региональная система забирает у другой ежесуточно данные, за прошедшие сутки, само собой.
Системы сильно разные, на совсем разных технологиях, из общего только то, что обе на интелах.
Иногда на системе, откуда забирают данные, случаются какие-то сбои, и они вынужденны откатывать данные на целый опер. день назад, и повторно потом загружать эти данные из файлов, в которых они поступают.
А системе, куда это загружается, это не нравится, она не умеет такие ситуации обрабатывать.
Поэтому давайте впердюлим репликацию, и она раз в сутки ночью будет перегружать эти данные.
И если на первой системе произойдёт сбой, и всё откатится на сутки назад, то вторая останется со своими данными.
Явная ведь несуразица, ведь через сутки опять будет сеанс репликации, и эти вновь залитые данные будут повторно реплицированы.
Спрашиваю, а не проше ли решить вопрос нормальным администрированием первой системы, которая на db2 L/U/W, ведь резервное копирование и архивирование журналов транзакций позволят восстановиться на момент сбоя, и не потребуется откатывать опер.день.
Нет, говорят, не легче - обученного персонала нет.
Отлично, а кто же тогда будет заниматься администрированием репликации, если это задача не в пример сложнее, чем однократная настройка регулярного резервного копирования и архивирования журналов?!
Спросите - а при чём тут мэйнфремы, статья?
А очень даже при чём.
Самая прямая связь.

13  
Действительно, причем здесь мейнфреймы, если в самой IBM, в крупном финансовом приложении, несколько мейнфреймов шлют свои базы файлами на главный мейнфрейм. А после ошибок все на ходу придумывают UPDATE чтобы всё привести к правильному виду. Не в мейнфреймах счастье, а в людях. smile

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]

Яндекс.Метрика