Delphi for zOS

[Мальчик-Одуванчик]

А по-моему была в 70-х годах система ADABAS, которая достаточно похожа на это новомодное порно. В CCCP тоже с успехом эксплуатировалась.

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

Я вообще-то структуру данных имел ввиду и её похожесть на нынешние монги.

[iDesperado]

Какaя в попу тогда параллель, с 29 мегабайтными дисками которые были как ведро!

и я о том же на шестой странице

key-vale и нолики и единички в 60х тоже использовали, но это не повод натягивать сову на глобус. суть map-reduce в разбивке задачи на независимые куски, которые можно обсчитывать в параллель. в 60х-70х параллельно даже перфокарты воткнуть не догадывались.

[Мальчик-Одуванчик]

Никогда СМ не шли вместо ЕС. ЕС шли в свою нишу н/х, СМ в свою. Были предприятия где было и то и другое. Никто даже не думал о замене одних другими.

На Дальнем Востоке ЕС, похоже вообще с какого то времени перестали закупать. На крупные предприятия типа вертолетного завода завозили СМ для всех типов задач. Они были менее прихотливы, особенно в отношении вибрации, загрязненности и размера.
.......

ЕС ЭВМ делались (для военных) в мобильном варианте, на автобазе Урал, а также ставились на подводные лодки. Были и ОС собственного изготавления, не ИБМ ОС.

Знакомый по универу распределился на базу атомных подводных лодок в Большом Камне, прельстившись квартирой.
Так на самой базе никаких ЕС и в помине не было, не уверен насчет самих лодок. Но если с научников, которые тогда больше на оборонку работали, ЕС сняли, то такая судьба могла постичь и лодки (если ЕС там действительно были)
Из ЕС, хоть как-то реально использовавшихся кроме расчета зарплаты мне известен лишь один случай её применения на телеграфе. Там она занимала целый этаж и требовала штата из более чем десятка человек в три смены.
Еще одна стояла на ВЦ железной дороги, но только для расчетов зарплаты и графиков движения. К примеру учетом грузов занимались уже на СМ.

[zVlad]

...
На Дальнем Востоке ЕС, похоже вообще с какого то времени перестали закупать.
......

Ни ЕС ни СМ не "закупались" их прежде всего распределяли, в Госплане. На основании заявок, конечно. Но просто поехать куда-то и купить - такого не было. Я работал в конторе занимавшейся установка и ЕС и СМ на предприятиях Челябинской области. К нам приходила информация кто , когда и что ожидает получить. Мы встречались с этими предприятиями и договаривались о вводе машин. "Программисты" на обе серии числились в одном отделе, два разных бюро.

[Мальчик-Одуванчик]

...
На Дальнем Востоке ЕС, похоже вообще с какого то времени перестали закупать.
......

Ни ЕС ни СМ не "закупались" их прежде всего распределяли, в Госплане. На основании заявок, конечно.

Эт-то понятно. Но в расчетах фигурировала стоимость железки. А поскольку хозрасчет в мое время уже был в обиходе, то от большинства ЭВМ открещивались как могли на всех уровнях и если не удавалось совсем отпихнуться, то соглашались на более бюджетные варианты. Вспоминаю как начальник автобазы костерил навязанную ему 1420: Если раньше он платил вполне вменяемые деньги за расчет зарплаты на стороне, то теперь только зарплата штату из двух операторов и начальника ВЦ не окупала полученной экономии. Это не считая затрат на содержание самой ЭВМ. Вдобавок пришлось отдать помещение так называемого красного уголка на размещение этого хозяйства. И подозреваю, были опасения что толкать налево запчасти, топливо и горюче-смазочные станет значительно труднее.

[zVlad]

...
На Дальнем Востоке ЕС, похоже вообще с какого то времени перестали закупать.
......

Ни ЕС ни СМ не "закупались" их прежде всего распределяли, в Госплане. На основании заявок, конечно.

Эт-то понятно. Но в расчетах фигурировала стоимость железки. А поскольку хозрасчет в мое время уже был в обиходе, то от большинства ЭВМ открещивались как могли на всех уровнях и если не удавалось совсем отпихнуться, то соглашались на более бюджетные варианты. Вспоминаю как начальник автобазы костерил навязанную ему 1420: Если раньше он платил вполне вменяемые деньги за расчет зарплаты на стороне, то теперь только зарплата штату из двух операторов и начальника ВЦ не окупала полученной экономии. Это не считая затрат на содержание самой ЭВМ. Вдобавок пришлось отдать помещение так называемого красного уголка на размещение этого хозяйства. И подозреваю, были опасения что толкать налево запчасти, топливо и горюче-смазочные станет значительно труднее.

Интересно читать Ваши истории. Я больше видел другие картины. Чистейшие, да огромные, залы, с несколькими ЕС-ками. Все работают и это очень даже нужно и очень даже окупается. Например, ВЦ ЖЕЛДОР Южного Урала. Две ЕС-1045 вводили там. Задача отслеживание движения вагонов. 15 минут простой системы следует доклад начальнику дороги и летят головы начальников на ВЦ. Все очень серьезно было. Одна ЕС-ка работала, вторая включена и готова принять работу если первая вылетит. Говорили не вылетала ни одна и чтобы проверить работоспособность переходили once in awhile с одной на другую.
Системы продажи желдорбилетов "Экспресс" тоже была ЕС ЭВМ.

[sp123]

Но не на 36К, больше, когда я пришел в ЧМК, там была ЕС-1061 с 4М памяти, а до того была пара ЕС-1033 и минимум 512К, две штуки было вроде. Что значит аппаратно-зависимой?

Был неправ. Погорячился. Вспылил .

[caltrain]

Вспоминаю как начальник автобазы костерил навязанную ему 1420: Если раньше он платил вполне вменяемые деньги за расчет зарплаты на стороне, то теперь только зарплата штату из двух операторов и начальника ВЦ не окупала полученной экономии. Это не считая затрат на содержание самой ЭВМ. Вдобавок пришлось отдать помещение так называемого красного уголка на размещение этого хозяйства. И подозреваю, были опасения что толкать налево запчасти, топливо и горюче-смазочные станет значительно труднее.

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

[Мальчик-Одуванчик]

Он не читал инструкций. А ведро спирта на такую машину в месяц полагалось.

Нифига не ведро, а всего лишь жалкие три литра. Забавно что на Меру, которая раза в четыре была меньше тоже три литра полагалось.
Зато был курьезный момент, когда персоналки завезли - под них тоже некоторое время спирт списывали.

[Boriskin]

Тот курс что преподавали был настолько нашпигован теорией что его сдать было не легче чем, к примеру, курс функана или теории групп.

В 90х был спецкурс "Параллельные ассоциативные вычисления", где под писюк был даже эмулятор, было очень интересно играться. Ортогональный подход так скзать.

Малышкин вел? Эт здорово что было на чем проверить полученные знания.

Не, тетенька кфмн была, фамилию не помню.

[caltrain]

Он не читал инструкций. А ведро спирта на такую машину в месяц полагалось.

Нифига не ведро, а всего лишь жалкие три литра.

он все одно паёк в ведре приносил, потому как принтеры... я ж говорю, инструкции читать надо

[perasperaadastra]

А вот на мейнфреймы спирт полагается (для протирки контактов)?

[Komissar]

А вот на мейнфреймы спирт полагается (для протирки контактов)?

еще как! На магнитные лентопротяжки уж точно.

[zVlad]

А вот на мейнфреймы спирт полагается (для протирки контактов)?

В 80-е годы на ЕС ЭВМ полагался Главным образом для дисков, которые были с'емные и пылились поэтому.

[zVlad]

А вот на мейнфреймы спирт полагается (для протирки контактов)?

еще как! На магнитные лентопротяжки уж точно.

Чтобы протирать магнитные головки,что делалось когда лента не читалась.

[nightmare2]

Честно говоря, для меня загадка, где стенькин видит что-то новое в javascript или той же mongodb.
Иерархические базы данных были отвергнуты очень давно, т.к. у них много недостатков по сравнению с реляционными.
Монгу склепали, что бы пацанчикам не знающим ничего кроме js , было удобно сливать куда-то json.
Для сайтиков-визиток конечно пойдет.
До этого у них там PHP с дивным MySQL был ихним всем.

Пожалуй, реально интересным из нового для web ui - это reactjs.
Из языков программирования - rust.

[Flash-04]

А что делать с информацией которая по определению в виде многосвязных графов?

[tessob]

А что делать с информацией которая по определению в виде многосвязных графов?

Черт с ними с графами. Есть заказ, у заказа есть позиции. ОК, сделали базу. Через год выяснилось, что у позиций есть подпозиции... Бяда!

И вот таких простеньких примеров у меня было вагон и маленькая тележка. Причем если с noSQL это в принципе не проблема, то в реляционных базах это редизайн и костыли, костыли, костыли. ))

А что касается графов, то их вполне можно хранить в плоской табличке с двумя столбцами, просто как кучу ребер. Производительность такого решения в расчет не беру.

[nightmare2]

А что делать с информацией которая по определению в виде многосвязных графов?

От задачи зависит.
Сам по себе граф - это просто какие-то данные.
Если я правильно помню, граф надо обходить для получения информации.

Можно хранить в таблицах.
Можно использовать специальные базы данных, такие есть (Ориент например).
У информикс когда-то была технология DataBlade.
Она позволяла создавать новые типы данных и встраивать операции с ними праймо в БД.

Ну и можно хранить как BLOB а обработку написать на C/C++/C#/Java/...
Для этого есть библиотеки и фрамеворки.

[Мальчик-Одуванчик]

Он не читал инструкций. А ведро спирта на такую машину в месяц полагалось.

Нифига не ведро, а всего лишь жалкие три литра.

он все одно паёк в ведре приносил, потому как принтеры... я ж говорю, инструкции читать надо

Не, таскалось все в трехлитровых банках. Сам их и таскал, когда просили помочь.
Возможно ведра до нас просто не доходили.

[katit]

А что делать с информацией которая по определению в виде многосвязных графов?

От задачи зависит.
Сам по себе граф - это просто какие-то данные.
Если я правильно помню, граф надо обходить для получения информации.

Можно хранить в таблицах.
Можно использовать специальные базы данных, такие есть (Ориент например).
У информикс когда-то была технология DataBlade.
Она позволяла создавать новые типы данных и встраивать операции с ними праймо в БД.

Ну и можно хранить как BLOB а обработку написать на C/C++/C#/Java/...
Для этого есть библиотеки и фрамеворки.

В том же SQL Server все есть. И в других думаю тоже.

[iDesperado]

Черт с ними с графами. Есть заказ, у заказа есть позиции. ОК, сделали базу. Через год выяснилось, что у позиций есть подпозиции... Бяда!

что за бяда ? чем появление таблички с подпозициями будет отличаться от появления подпозиций в каком-нибудь json ?

[tessob]

2 iDesperado: Признаю, что криво выразил свою мысль. Представим, потом еще выяснится, что есть еще разные виды заказов, у которых отличается структура позиций и подпозиций. Например, длинны и/или количества полей разные и т.п. В общем изменения происходят постоянно и уйти от этого не возможно. В итоге база начнет описывать сразу несколько концепций хранения данных. Вот, ИМХО, в таких случаях noSQL имеет преимущества т.к. мне не нужно поддерживать в SQL легаси поля. А так же мой json описывает реальные данные именно в том виде, в котором их необходимо хранить. При этом мне не нужно думать в каких случаях и для каких объектов какие таблички и поля нужно читать, а какие нет.

З.Ы. Может конечно это только мне так со SQL не везло. Хотя признаю, что иногда SQL лучше. Вообще-то я сторонник комбинирования обеих технологий, если это необходимо.

[iDesperado]

2 iDesperado: Признаю, что криво выразил свою мысль. Представим, потом еще выяснится, что есть еще разные виды заказов, у которых отличается структура позиций и подпозиций. Например, длинны и/или количества полей разные и т.п. В общем изменения происходят постоянно и уйти от этого не возможно. В итоге база начнет описывать сразу несколько концепций хранения данных. Вот, ИМХО, в таких случаях noSQL имеет преимущества т.к. мне не нужно поддерживать в SQL легаси поля. А так же мой json описывает реальные данные именно в том виде, в котором их необходимо хранить. При этом мне не нужно думать в каких случаях и для каких объектов какие таблички и поля нужно читать, а какие нет.

тут как раз у SQL преимущество - ты просто увеличиваешь размер поля, добавляешь колонки и в отличие от бигдата ничего нигде не падает. в оракле вообще иделаьно, с его %ROWTYPE или %TYPE. и в этом плане после оракла на бигдата плакать хочется. у нас последние три релиза падали, потому что в paquet не та версия avro, какую код ожидал. с точки зрения оракла просто дикость.

[Flash-04]

Есть довольно большая область работы с данными где SQL не только не нужен, а даже мешает: log management. Я давно с этим работаю и воочию наблюдал как вендоры начали с SQL БД и потом были вынуждены уйти к noSQL именно из-за проблем с производительностью.