См. в документации $ZUTIL(140,13,dir)

Блок А.Н.Неа

Ха. У меня где-то и Cache 4.1, возможно, завалялась. Уверен, что функция $ZUTIL(140,13) работает, начиная с Cache 2008.1, а может быть и с более ранней. Как вы, конечно, знаете, класс %File использует её же.

P.S. Пришлось пересесть на Cache 5.0? Неужели всё так плохо (сочувствую)?

Блок А.Н.,

Проверил, подфункции с n>10 появились, начиная с Cache 5.1 . Подумайте об апгрэйде...

Блок А.Н.,

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

Хороший вопрос, возможно, достойный отдельной темы. Допустим:
- есть прикладная система в Cache, разработанная вами или вашими коллегами,
- версия Cache постепенно устаревает,
- принятие решения об обновлении версии Cache зависит от вас.

Чем вы руководствуетесь, принимая решение: настала ли пора обновить версию Cache?

krvsaКто оплачивает покупку новой версии и сам переход?Cache под сопровождением, новые версии доступны, покупать не надо.

Сам переход: прикладное ПО тоже под сопровождением, т.е. с точки зрения заказчика, "all inclusive". Команда разработчиков - ваша. Дополнительные платежи 3-м фирмам не требуются.

AlexKBстоимость лицензий Каше составляла 1.5-3 процента от общей стоимости проекта,Чтоб я так жил...
AlexKB...но именно стоимость покупки лицензий Каше всегда вызывала у Заказчиков много сомнений и вопросовПри таком невысоком проценте от всего "пирога" стоимость, возможно, была лишь предлогом, а первопричиной - что-то иное.

krvsaУ нас все обновления делались только тогда, когда клиент соглашался все это оплачивать. Кто не оплачивал - так и сидит на старых версиях Cache.Тогда это не "all inclusive" уже. Понятно, что нюансов много в каждом отдельном случае. Где-то нужны командировки, а где-то можно удалённо - большая разница.

Попробую переформулировать вопрос:
- Допустим, клиент всё оплатил, и решение об обновлении версии отдал на усмотрение поставщику ПО (т.е. вам). Допустим, это можно сделать удалённо.
- При каких условиях вам, как ЛПР, покажется выгодным обновить версию Cache у заказчика?

AlexKBСтоимость разработки ПО составляла 10-15% от общей стоимости проекта.Тогда 1.5-3% на лицензии составят около 20% стоимости ПО, что не так уж плохо. Да я и не завидую (так, фигура речи - неужели без смайликов мы уже плохо
понимаем друг друга))).

Alexey MaslovОсновные сомнения заключалось в том, что "...мы Каше не знаем, никто его не знает, так он еще и денег стоит!"В этом скорее всего и дело. Предложи вы даже бесплатный аналог, всё равно могут сказать "никто его не знает". В этом смысле может оказаться чуть проще не выделять СУБД как отдельную сущность при поставке ПО, т.е. брать ответственность за всё.

Но я не про новые поставки, а про обновление существующих. Допустим, с денежной стороной всё ОК, и начальство вменяемое. "Нагнуть за зарплату" - странная формулировка: можно за ту же зарплату загрузить сотрудников разработкой новой функциональности и получить какие-то дополнительные "плюшки" от клиентов, а можно потратить сопоставимое время на тестирование существующего ПО под релиз-кандидатом СУБД.

Какие технические факторы побуждают вас к обновлению версии?

Напишу, что подталкивает меня (порядок перечисления не соответствует приоритетам):
1 - вывод версии из числа поддерживаемых ISC (истечение даты окончания поддержки).
2 - удобно, когда у большинства клиентов одинаковые версии. "Зоопарк" неудобен по многим причинам, не буду подробно расписывать.
3 - может оказаться, что ОС, на которую ставится ваша "любимая" версия, уже не поддерживается её поставщиком. Ставить старую ОС на новый сервер, даже если это позволяет лицензия, удовольствие ещё то: поставщики железа довольно быстро прекращают выпуск драйверов под устаревшие ОС. Да, виртуалки позволяют частично это преодолеть.
4 - в СУБД появилась новая функциональность, которая выигрывает от установки новой версии. Если даже она не будет использоваться всеми клиентами, всё равно, учитывая (2), хочется подтянуть всех. Например, зеркало (Mirror) было одним из побудителей к обновлению из 2012.2 в 2015.1.
5 - появились приятные "плюшки" для программистов. С этим сложнее: "в поле" ещё долго остаётся старая версия СУБД, значит, либо отказаться от использования "плюшек" совсем (ну или до тех пор пока всех клиентов не обновим), либо плодить ветки кода.

Блок А.Н.Кстати, 2009 хорошая версия. С нее мне удалось перейти только на 2014. В 2010, 2012, если мне не изменяет, в нашем режиме работы были какие-то странные фризы веб-шлюза.Это во многом зависит от потребностей приложения и его разработчиков. Даже не хочется вспоминать неприятности, которые нас ожидали в версиях 2009 и 2011, не заметь мы их вовремя.

Вот смотрю сейчас на 2017.2.0.744: проблем особых пока не выявил, и <minor version number>= 2, что хорошо, но <point version number>=0 до сих пор, и похоже основные силы брошены на IRIS (2018.1). Перешёл ли кто-нибудь на 2017.2 промышленно?

DAiMorВроде как давно уже 2017.2.1.801.0 вышла. У меня пока только один проект все еще в разработке. А на втором сейчас пока 2014, 2017.2 только тестировали, но сейчас, и еще больше после сегодняшнего саммита, думаю про IRIS...
Cache/Ensemble 2018.1 будут...Спасибо, а я как-то проморгал выход 2017.2.1.

Вот и мне кажется, что надо готовиться к IRIS, несмотря на то, что ансамблевая часть нами скорее всего не будет востребована. Но ведь отдельно Cache поставляться больше не будет, не так ли? Почему-то думал, что Cache 2018.1 - это уже IRIS.

DAiMorА действующим не будет никаких препятствий оставаться на Caché и Ensemble, которые будут обновляться...Раньше звучало несколько иначе, что выпуск отдельных продуктов прекращается, а будет единый IRIS. Или мне это только почудилось?

Интересный момент: будут ли синхронизированы сроки выхода релизов (и, соответственно, версии ядра) в IRIS и в Cache?