zVlad wrote: ↑25 Apr 2021 15:14
А что было не так? О каком DB2 речь? Полагаю не о DB2 for zOS.
Базу арендовали у IBM в их же датацентре. Какая там была версия БД и ОС - понятия не помню. Были проблемы с запросами, влоть до загадочных синтаксических ошибок. После мучений подобрали специальную версию драйвера с определенным набором флагов и велели всем ничего больше не трогать.
Если это была DB2 for zOS, то должна была бы идти речь о DB2 Connect. Если не было речи о DB2 Connect то мог бы быть драйвер от third-party (связанного с TIBCO, забыл их название), был у нас такой в начале 2000-х. Пока не заменили на IBM DB2 Connect и нас колбасило.
Но это уже не про IBM история.
Какое еще TIBCO? Я же написал - базу и все вопросы с ней связанные поддерживал IBM. Они же и драйвер подбирали.
Я думаю что Вы работали исключительно как программист. Поэтому Вы просто ничего и не знали что, как и почему. В том числе проблема могла быть и в .NET.
TIBCO это разработчик middleware. Они все со всем свызывали, но довольно неуклюже. Они и сейчас есть - шлют мне аннонсы чуть не каждый день и отписаться от них не удается.
zVlad wrote: ↑26 Apr 2021 16:13
Я думаю что Вы работали исключительно как программист. Поэтому Вы просто ничего и не знали что, как и почему. В том числе проблема могла быть и в .NET.
А вам-то, заносчивому не по должности DBA, откуда знать про проблемы разработчиков? Вы хоть раз хоть одну строчку кода в production выпускали?
zVlad wrote: ↑26 Apr 2021 16:13
Я думаю что Вы работали исключительно как программист. Поэтому Вы просто ничего и не знали что, как и почему. В том числе проблема могла быть и в .NET.
А вам-то, заносчивому не по должности DBA, откуда знать про проблемы разработчиков? Вы хоть раз хоть одну строчку кода в production выпускали?
zVlad wrote: ↑26 Apr 2021 16:13
Я думаю что Вы работали исключительно как программист. Поэтому Вы просто ничего и не знали что, как и почему. В том числе проблема могла быть и в .NET.
А вам-то, заносчивому не по должности DBA, откуда знать про проблемы разработчиков? Вы хоть раз хоть одну строчку кода в production выпускали?
Вы просто не знаете разницу между DBA на МФ и DBA на других платформах. Тоже самое касается системных админов на МФ и других.
Да, я написал достаточно программ и не только для баз данхных чтобы отлично знать чем владеют и чем не валадеют просто разработчики для баз данных такие как Вы. Вы знаете базу данных как исполнителя SQL statements и не более того. Я знаю все это тоже плюс еще многое другое чего Вы не знаете. Вы даже не знали на какой платформе та DB2 выполнялась и какой драйвер к ней был установлен. И при этом считаете себя в праве судить чтоо и как делали ИБМ-овцы для вас - разработчиков.
Дебагер им не понравился, птыть.
Большинство Linux пользователей вообще сидят под GDB. Учитывая, что это сейчас стало основной платформой, то можно сказать, что IBM опередил всех.
А мне думается что проблема вовсе не в мейнфреймах.
Я сталкивался с такими же проблемами в приложениях на банальных джавских фреймворах.
Дело в приложениях, а точнее - в отношениях клиентов и разработчиков.
Надо попробовать вывести короткую и емкую формулу...
Предложу определение для проблемы: Синдром мастера Айкидо.
Ходили рассказы про то как на татами выходил сухонький старичок, и несколько здоровенных бойцов не могли сдвинуть его с места.
Так и с приложениями: вроде бы логики там на 3 строчки, данные уместятся в старенький смартфон, по ресурсам его можно запихать в wrt router, а все попытки его перенести на "нормальную" платформу с треском проваливаются.
Условия возникновения проблемы:
- Приложение реально решает какую-то важную проблему (Mission Critical App)
- Пользователи имеют решающий голос в том как система должна работать, а главное - как она должна меняться
- Пользователи в целом удовлетворены тем как система работает
- Пользователей не сильно много и/или они разделены на разрозненные группы.
Дебагер им не понравился, птыть.
Большинство Linux пользователей вообще сидят под GDB. Учитывая, что это сейчас стало основной платформой, то можно сказать, что IBM опередил всех.
большинство пользователей линукс это php, java, pl/sql - на кой им GDB ? у 99% пользователей линукс шикарные ide с шикарными дебагерами. думаю и те кто ядро ковыряют, сидят на платных инструментах.
Механизм возникновения проблемы:
- Пользователи нагибают разработчиков чтобы требуемые фичи были сделаны именно так как они хотят, срок исполнения - вчера
- Разработчики проявляют гибкость, и любой ценой исполняют желание заказчика
- В результате появляется Technical Debt
- Платформа грамотно спроектирована, хорошо поддерживается и обладает достаточной гибкостью чтобы скомпенсировать этот долг
- Долг накапливается, появляются все новые хаки добавленные второпях, чтобы ублажить строгого заказчика.
- Самое главное: возникает сакрализация этого долга: его начинают боятся, как монстра из темного угла, ненавидеть, перенося гнев на платформу, инструменты и проч.
Кстати, судя по статье в zOs были популярны шареные области между процессами. В vax vms тоже. Тогда это считалось классным.
Современной подход с кучей тредов (большому процессу со своими то данными в thread safe манере разобраться, не то что чужими) сильно уменьшил возможности использования таких подходов
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
iDesperado wrote: ↑03 May 2021 06:20
большинство пользователей линукс это php, java, pl/sql - на кой им GDB ? у 99% пользователей линукс шикарные ide с шикарными дебагерами. думаю и те кто ядро ковыряют, сидят на платных инструментах.
Какие это нафиг пользователи Линукс? Эти водят себе мышкой в своем шикарном IDE под виндой, и в лучшем случае только догадываются, что что-то там под Линуксом будет деплоиться.
Dmitry67 wrote: ↑03 May 2021 07:28
Кстати, судя по статье в zOs были популярны шареные области между процессами. В vax vms тоже. Тогда это считалось классным.
Современной подход с кучей тредов (большому процессу со своими то данными в thread safe манере разобраться, не то что чужими) сильно уменьшил возможности использования таких подходов
Судя по статье, Дима, и я об этом там уже написал, автор сам не очень то понимает где он работает, но поскольку их команде дают высокеи права и следуя их стилю из Юникс и С они пытаются создавать себе проблемы тем что слишком много делают на уровне ядра системы вместо того чтобы использовать системные возможности, которых они не знают. Я могу ошибаться, но в статье мало конкретики.
Palych wrote: ↑03 May 2021 06:34
Механизм возникновения проблемы:
- Пользователи нагибают разработчиков чтобы требуемые фичи были сделаны именно так как они хотят, срок исполнения - вчера
- Разработчики проявляют гибкость, и любой ценой исполняют желание заказчика
- В результате появляется Technical Debt
- Платформа грамотно спроектирована, хорошо поддерживается и обладает достаточной гибкостью чтобы скомпенсировать этот долг
- Долг накапливается, появляются все новые хаки добавленные второпях, чтобы ублажить строгого заказчика.
- Самое главное: возникает сакрализация этого долга: его начинают боятся, как монстра из темного угла, ненавидеть, перенося гнев на платформу, инструменты и проч.
И все, "больше уже никто никуда не идет"
Добавлю пункт:
- разработчики плохо знают еше меньше понимают платформу. Лезут в ядро, применяют привычки с других платформ где получили образование в ИТ, и далее по Вашему списку.
У меня тоже много программистов, но их дальше Кобола не пускают. В системе все стабильно и спокойно. Программисты удовлетворяют все хотелки клиента.