Позвольте мне вставить и свои пять копеек.

Лично я столкнулся с необходимостью устанавливать временный запрет для регистрации в задаваемых областях новых пользователей, что-то по аналогии с полным запретом регистрации новых пользователей во всех областях <$$%swset^SWSET(12,1)>.
Считаю, что такой функционал позволил бы управлять балансированием нагрузки на систему при различных пиковых ситуациях.
Т.е. некий процесс диспетчер выполняет анализ на прикладном уровне и при необходимости ставит временный запрет на регистрацию новых подключений к некоторым областям. При снижении нагрузки - снимает запрет.
Пока не могу ничего сказать по поводу CSP-подключений, но для CallIn и DirectAccess подключений это было бы решением проблемы. Оба эти интерфейса позволяют осуществлять доступ к любым программам и данным, при этом проконтролировать такой доступ все-таки представляет определенные трудности. Доступ же к другим областям остается на прежнем уровне.

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

Ну что же, давайте обсуждать.
Постараюсь выдержать любую критику и намотать на ум все Ваши разумные доводы.

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

DAiMor,
Честно говоря, ничего не знаю - бегло прочитал только...
Но, мне не нужно закрывать полный доступ к серверу, а только к определенным областям. Мне нужно постоянно менять правила доступа к этим областям, т.е. нерегулярный поток изменения конфигурации доступа к областям (список областей меняется) на пиках 5-30 секунд. Изменять правила доступа не вручную, а по определенным алгоритмам, которые исполняет Каше диспетчер-процесс.
Там такое возможно?
К тому же никто не будет видеть никаких страничек, поскольку в Каше ломятся приборные драйвера.
И самое главное, я отчетливо вижу, что такое управление доступом необходимо замыкать внутри Каше.

servit,
Вот в этом направлении покопаюсь, спасибо за наводку, хотя скажу заранее, может и не подойдет.
В принципе можно оперировать и понятием БД, а не область, т.е. управлять доступом сразу к нескольким БД, которые составляют требуемую мне область.
Единственное что меня смущает, так это то, что я должен оставить возможность доработать тем процессам, которые уже приконекчены в настоящее время и никоим образом не ущемить их потребности. А вот новым дать запрет на доступ на некоторое время, они свой поток данных сбуферируют у себя и чуть позже вывалят свои данные. И еще, мне неважно кто именно стучится, мне важно чтобы они не начали сыпать мне новые данные.
И еще, это не связано с лицензионными ограничениями, это только связано с балансированием нагрузки на прикладном уровне.
Сервер все равно справляется, запас производительности достаточен.

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

Ведь только благодаря многим уникальным возможностям Каше и есть, чем он есть!

DAiMorAlexKBА вдруг разработчики сидят и ломают голову - чтобы еще такого хорошего придумать.Думаю им точно нет времени так думатьКак сказать...
Когда-то я очень долго ныл по поводу, что хорошо бы иметь , на уровне команд языка COS, преобразования float чисел во внутреннее представление числа и наоборот, а также длинные целые, битовые.
Хотя я тогда обходился и своими силами, начиная от программок написанных на Каше, до всяческих приблудных длл-лек, шмакадявок и прочей нечисти. Это решало проблемы, но тянуло за собой ряд других (не буду их перечислять, скажу только что они были и не мало). И вот свершилось чудо, а может просто добрые люди поселились в Интерсистемс - они включили такие преобразования и дали их прикладникам (а ведь могли бы их замкнуть внутри себя, если они были только им нужны на внутреннем уровне). Более того, они учли и чередование байтов, а это говорит о серьезности их подхода. Думаю, почти уверен, что почти никто не пользуется такими возможностями, поскольку они нужны только тем, кто работает с различными приборами и промышленными протоколами связи.
Но тем не менее, ценность такой доработки очень высока, хотя она практически не востребована.
Скажу больше, многие системы автоматизации промышленных процессов так и не имеют подобных решений до настоящего времени... И это является довольно-таки серьезной проблемой, если такая система выступает в качестве интегрирующего звена крупного промышленного решения.
А я много повидал различных систем автоматизации промышленных процессов и скажу вполне ответственно, что Каше заслуживает особого внимания как для разработчиков систем автоматизации, так и для разработчиков компании Интерсистемс.
Уже давно пора Каше осваивать новые горизонты, и уже давно пора смотреть специалистам Интерсистемс на новую нишу, на новую плоскость соприкосновения.

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

Так что моя просьба об улучшении функциональности была не просто сиюминутной просьбой для решения частной и узкой моей собственной проблемы. Я вижу перспективу использования такой функциональности в будущем.

Уважаемые форумчане, перестаньте думать о том, что Каше нужна только для бухгалтерии (образно)!
Каше нужна и в сфере промышленной автоматизации, там сейчас завал, давно существующие решения уже не справляются со все растущими задачами промышленной автоматизации.
Единственно нечто похожее я видел только в технологии AspenTech, и ихнем сервере IP21, но уже давно не смотрел в ту сторону...

Alexey Maslov,
Объектом для нового внешнего подключения все же является область, ее мы всегда задаем в качестве параметра соединения при любом способе подключения. Тот системный процесс, который анализирует все новые входящие запросы на подключение, наверняка может отбить такие запросы, если есть в том такая необходимость. И этому системному процессу абсолютно все равно, какие базы собраны в эту область, какие глобалы переданы в эту область, до этого даже дело не дойдет. То что работающие задачи переключаются между областями, так и пусть себе переключаются, пусть себе порождают новые JOBы в разных областях. Они уже работают и не будем им мешать. Я говорю только о новых внешних подключениях к определенной области, просто не устанавливать новое соединение. Для того, кто пытается подключиться это будет выглядеть всего лишь как неудачная попытка соединения, которую он попытается повторить позже.(ну наподобие временного отсутствия связи). Главное, чтобы новое подключение не состоялось, а не было прервано на прикладном уровне после его выполнения. Повторюсь еще раз, входное соединение, в качестве параметра передает область, в которую просит подключиться. А мы ему говорим - извини, на данная область временно недоступна, подключайся позже, или подключайся в другую, альтернативную область. И это уже третий вопрос, что и основная и альтернативная область может собираться из одних и тех же глобалов, или баз данных.

DAiMor,
Увы, в %ZSTART область для нового подключения не всегда видна.

servitAlexKBУвы, в %ZSTART область для нового подключения не всегда видна.Приведите код %ZSTART.

Интересно, и что же такого Вы хотите увидеть в этом коде..?
Вопрос обсуждения ведь состоит не в моем коде. Я ведь не ставил вопрос таким образом, мол помогите решить проблему. Я ставил вопрос о желательном развитии функционала в том направлении, что заявил. Я вижу его полезность в будущем для решения некоторых вопросов, я их озвучил. Вы же (я имею ввиду не Вас лично) мне предлагаете некоторые частные решения, которые на Ваш взгляд могли бы явиться альтернативой. Я привожу свои доводы, оппоненты, кроме единственного не привели - у разработчиков нет времени. Если бы Вы привели довод такого плана, что дополнительная проверка в момент разрешения регистрации в Каше увеличит время регистрации на 5% (а это было бы недопустимым с моей точки зрения), или появятся другие накладные расходы, что это приведет к иным последствиям там-то и там-то, тогда да, есть над чем подумать, мол стоит ли овчинка выделки. А так, если появление предлагаемой мной функциональности никоим образом не отразится на работе систем, построенных и проектируемых на базе Каше моими оппонентами, то получается, что обратных доводов у Вас просто нет.
Вот Алексей Маслов высказал свое пожелание, я его вполне поддерживаю - разумно иметь единый механизм решения вопроса, но двумя способами (или быстро, или точно - решает пользователь). Но ведь на сегодняшний день есть пути решения, зачем чего-то переделывать специалистам Интерсистемс? Но я за переделку, это было бы разумнее.

А код, да пожалуйста...  //%ZSTART
  quit
  //
JOB ; JOB'd process exits. 
  set $ZTrap="Error"
  set zapret=$g(^|"%SYS"|LLGG("ConnectDisable"),0)
  if zapret=1 {
    for i=0,1,4:1:15 set a(i)=$zu(67,i,$j)
    hang 200  // тут я смотрю в портале какими возможностями управления процессом я обладаю в данной точке исполнения
  }
  quit
  //
Error
  set $ZTrap=""
  quit
  //

Alexey Maslov,
Я ведь писал уже, что область, куда происходит соединение, проверить невозможно. В этом случае - она будет равна "%SYS", при любом способе ее получить.
Я ведь сознательно не привел в своем коде чему равна область...
a("$zu(5)")="%SYS"
a("znspace")="%SYS"
a(6)="%SYS"

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

Alexey Maslov,
Вот, вот...
Только через проверяльщик мне не подходит, слишком много нехорошего родительский процесс сможет натворить, даже если я отловлю его и прибью через 20 мс...
На данный момент для меня все это не критично, но я думал над перспективой и было бы хорошее для меня решение одного из вопросов будущей разработки, если бы я смог воспользоваться функциональностью, о которой говорил...
А вопрос возник еще и потому, что вроде бы в одной из реализаций МАМПСов, с которыми я работал, такая возможность была...
Не берусь утверждать, но что-то такое крутится в голове...