Насчёт общения по поводу M (не Cache/IRIS): видимо, совсем мало такого народа, кому
a. это интересно
b. надо именно по-русски.

Xоть и мало активна, но до сих пор жива https://groups.google.com/g/comp.lang.mumps?hl=en ; за ломаный аглицкий там не припомню, чтобы пинали.

И потом: если мы ничего не пишем в наш форум на sql.ru, с чего вдруг начнём писать в какое-то другое место (группу, дискорд, etc)? Видимо, темы для разговоров иссякли, а не потому, что мы такие олдскульные, не можем разобраться с дискордом и прочим.

Нравится / не нравится, но с системными классами работать так или иначе придётся, т.к. в Cache давно уже нет полного функционального покрытия %-утилитами.

DAiMor,

спасибо, интересно.
Насколько понимаю, ты разобрался в протоколе супер-сервера (ODBC?) и по нему общаешься с IRIS?

Это оценочное суждение ))
В начале 0-ых все наши клиенты, кто был под сопровождением, перешли из MSM в Cache. Пик миграции пришёлся на 2002-2003 годы, последнюю делали в конце 2005 года. Тиражируемые поставки собственных приложений у нас пошли сразу в Cache, при том, что вплотную работать с ней начали с 1999 года.

Сейчас темпы перехода на новую платформу несравнимо ниже. Возможно, это чисто российское явление (законодательные ограничения, импортозамещение...). Интересно, как обстоят дела в мире? Сменили ли "лошадку" крупные игроки, такие как Epic, Cerner?

P.S. Пользуясь случаем, хочу поздравить Дмитрия с победой в очередном конкурсе на community !

P.P.S. Хоть я и не до конца понял, зачем нужна эта Node-Red...

Это 2-й ребрендинг в их истории. Предыдущий был 25 лет назад. Тогда переход от *М к Cache основной массы пользователей занял около 7 лет.

Сейчас могло бы пройти быстрее, т.к. продукты значительно ближе друг к другу, но складывается впечатление, что ISC искусственно усложняет процесс, пытаясь на нём заработать. В итоге может получиться и подольше. Рад бы ошибиться, но поживём - увидим.

Using the Cache ^%R Routine

MX-9,

С MAC-программами такой номер не пройдёт.

С праздником:
Мампсистов и мампсисток,
Кашистов и кашисток,
Ирисов и ирисок!

P.S. Alatalo, а что, в Финляндии 13.09 тоже праздник?

...и вообще основная активность давно уже перешла туда.

Вот интересно: там есть японский, китайский и пр. переводные разделы.
Русского нет, потому что нас слишком мало, или тут другая причина?

Если делать для 5 человек, то да. Если же для 100 человек, то они обычно могут выбрать из 5 вариантов 1, который устроит хотя бы половину.

Весь вопрос, существуют ли в мире эти хотя бы 100 M-программистов, которые до сих пор мечтают о том, что наступит "Счастье для всех, даром, и пусть никто не уйдет обиженный! (c)"?

Сравнивать бесплатные версии коммерческих СУБД конечно можно, но есть ли в этом глубокий смысл? Ясно, что их основное назначение - привлечь новых партнёров-разработчиков, чтобы "коготок увяз", остальное - частности. Можно, конечно, обсуждать, насколько хорошо они с этой задачей справляются. Про Oracle, например, пишут Пара слов о базах данных Oracle
...
Бесплатная версия БД Oracle 11g(XE, Express Edition):
В свою очередь, Oracle предлагает бесплатную версию своего продукта (XE, Express Edition), которую Вы можете использовать свободно и совершенно бесплатно. Разумеется, Oracle наложила ограничения на свой бесплатный продукт, поэтому версия XE, может работать только с 1 ядром, 1 GB оперативной памяти и хранить данные не более 11 GB. Этого вполне достаточно, для одновременной работы с базой данных сотрудников малого предприятия, либо сотрудников отдела крупной компании. Возможно, что и для Ваших потребностей подойдет именно эта версия. (Разумеется, столь серьезные ограничения, заставляют все больше склоняться к openSource продуктам, например к таким как PostgreSQL).
Сравнивая с ограничениями IRIS Community Edition, приведёнными ранее, можно сказать, что в случае IRIS ситуация несколько лучше. Но толку? Вряд ли кто-то будет выбирать между столь различными СУБД, сопоставляя их бесплатные версии. Скорее, поищет бесплатный аналог, и возможно, его найдёт.

Системы, которые никто не обновляет, нередко живут очень долго, тем более на хороших серверах, и когда ни у кого из местных "руки не чешутся".

Наверное, всё-таки да: некая фирма попала под санкции, а это для любого бизнеса малоприятно. Ничего про это не знаю; DAiMor если захочет, расскажет.

P.S. А те, кто так назвал учреждение, видимо, не знают или не хотят знать истории. Могли бы назвать как-то иначе, e.g. "Верховна прокуратура України".

ГПУ - "...как много в это звуке для сердца русского слилось".

Господа, не ссорьтесь. Универсальную максиму "Shit happens" никто не отменял, а проблемы с производительностью практически всегда решаемы: это лишь вопрос времени и желания их решать.

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

krvsa , да пусть пишет: «Пусть расцветают сто цветов, Пусть соперничают сто школ» (c)

Вот все молчали, и из IRIS таки выпилили почти все объектные "биндинги". Мы, например, кое-где использовали %Net.RemoteConnection, пришлось переделывать - лишняя работа, ради чистоты чьей-то идеи: мол, объектные СУБД стали непопулярны. Можно подумать, что хоть когда-то были .

Это вряд ли:
"Марксизм для нас — азы,
Ведь Маркс не плыл в Янцзы..." (с)

С какой целью интересуюсь: есть одна разработка, где удалённые вызовы методов классов были изначально реализованы через %Net.RemoteConnection. Примерно год назад для совместимости с IRIS переделал на JDBC. Получилось довольно монструазно, но работает, заметной разницы в скорости нет.

Вот и подумал: есть ли смысл смотреть в сторону "Native API" как более лёгкой альтернативы?

Имел в виду, какой драйвер на стороне клиента? JDBC?

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

Если по делу, то можешь добавить пару слов подробностей:
Какой стек протокола используется на клиенте для подключения к 1972/tcp (суперсерверу)?

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

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

"Молодых" вендоров Стандарт должен интересовать больше: им пока что есть кого переманивать. Вот пусть и скажут своё слово.

Оставлять ли в ^|окружении| переменную или заменять её значением, дело вкуса, но написанное выше просто неверно: выражение разрешится в ^|EXPU|PUTLgod, и что, у нас есть переменная EXPU? Будет <UNDEFINED>.

Поэтому:

Просто синтаксис расширенной глобальной ссылки допускает указывать между | переменную, которой присвоено значение окружения; это может быть область (e.g. "EXPU") или предполагаемая область ("^^полный путь к БД"), есть ещё ряд вариантов.

ValeriuНа этом форуме вроде обсуждают на счет стандартаНе слишком-то обсуждают. Упомянули "new $test" (о чём ранее писал Евгений), а также K.S.Bhaskar (YottaDB) подчеркнул, что займётся разработкой нового Стандарта, лишь когда этот процесс станет открытым для всех членов М-сообщества.

Продолжается ли сам процесс разработки, есть ли результаты, каковы перспективы? - давно никаких новостей. Может быть, Евгений нам что-нибудь поведает.

Существуют реляционные БД, не поддерживающие SQL "из коробки". Для таких БД могут быть полезны инструменты, подобные Octo. На моей памяти это уже 3-й подобный инструмент для М-систем, он первый лишь для пользователей YottaDB.

Насчёт "языка запросов к глобалам" - такой язык есть, называется M. Глобалы ориентированы на навигационный доступ. Заметьте, что когда функции доступа к глобалам пытаются добавить в другой язык, принципиально ничего не меняется, громоздкость добавляется, и всё. Чтобы выйти на уровень декларативного языка, нужно... что-то декларировать, например, таблицы, которые без проблем "натягиваются" на глобалы, причём многими способами.

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

С традиционными ! и & не всё так просто: в Стандарте M-1995 не сказано, что необходимо вычислить все операнды выражения вне зависимости от того, влияют ли они на результат. Однако в большинстве М-систем они вычисляются. YottaDB составляет здесь исключение, с некоторыми оговорками.