So ... before you go changing those globals (if you haven't done so already), try

TIE> do ##class(Ens.Queue).AbortQueue("queuename") 

Once you've turned down all of the inbound services/processes. If that doesn't work, use my previous suggestion.

I do think you should shut down the services and processes feeding the routers. And it wouldn't hurt to shut down the routers as well.

If the count is still at 1 after you do that, set the value to 0. And I actually think that the job IDs are from the source services and processes, not the routers themselves.

From the Cache prompt in  your production's namespace, what do you see when you type:

PROD> zw ^Ens.Queue("QueueName")

?

Replace QueueName with the name of the queue in question ...

Yes, that should be safe to do with a running production.

Yes, the fact that the Output window lets you interactively enter commands makes "hacking" a bit easier, but so do the "Run" and "Debug" menu options

I'm curious to know if there's a way to limit a user to writing COS while prohibiting compilation or execution ...

And a server -side configuration option that makes the Output window read-only

Wow, I would think this is a potential security risk. I'm assuming the smart IRIS/Cache Administrator would remove any permissions to create or modify web app settings ...

The answer, while very clever, also assumes access to tools other than Studio. Can the requested solution be provided with Studio alone, and, more importantly, will it be possible for the administrator to prevent this sort of access?

 The other thing that just occurred to me is that the vendor is dumping a stack trace that may contain print control characters such as carriage returns, and the operation is simply treating the first \x0d as the end of the segment. That would effectively exclude the rest of the stack trace from the message body for conventional parsing purposes. The data is likely still there, but it can't be parsed out as part of MSA;3 with the parsing rules defined in the ACK's schema.

Thank you @Eduard Lebedyuk! Good to know

The only reason I can think of doing it the way it was done is that there was no expectation by the original author of the code that the JSON object would be larger than 32KB. It's also possible that he/she was unfamiliar with the types of objects that %FromJSON() works with and always assumed it was a simple string ... which is what the ReadLine() method returns.

Here's the documentation for for the %FromJSON() method.

Probably something like this (I'm not sure of the full name of the osuwmc.PatientBilling... class, and you probably want to do some sort of exception handling or at least error checking):

       set callrequest = ##class(osuwmc.PatientBilling.DataStructures.SelectResearchID).%New()

       set callresponse = ##class(EnsLib.SQL.Snapshot).%New()

       set callrequest.ResearchID = context.RschMRN

       do process.SendRequestSync("PatientBillingDBPoll", callrequest, .callresponse)

       set context.ClarityRS = callresponse

The default behavior of SendRequestSync is to never timeout, but you can always include a -1 as the 4th parameter to be a bit more descriptive.

It's explained pretty well in the documentation. It allows the synchronization of the call to be retried repeatedly when the timeout is reached. You specify the <call> to sync, the timeout, and whether resync (retry) is allowed. I'm not sure if there's any benefit to using it over the SendRequestSync() method, though.

I guess it's worth trying, but I have a gut feeling that it won't work. If it doesn't ...

You could accomplish this in a BPL, but you would have to build the response logic from the BO along with the filtering/routing logic.

You could alternately create a custom BO that simply generates NACKs and set the send target in your otherwise to that ... just override the OnMessage() method:

Class HICG.HL7.Operation.NackFactory Extends Ens.BusinessOperation
{

Parameter INVOCATION = "Queue";

Method OnMessage(pRequest As EnsLib.HL7.Message, Output pResponse As EnsLib.HL7.Message) As %Status
{
    Set pResponse = ##class(EnsLib.HL7.Message).%New()
    Set pResponse.DocType = "2.3.1:ACK"
    Do pResponse.SetValueAt(pRequest.GetValueAt("MSH"),"MSH")
    Do pResponse.SetValueAt("ACK","MSH:9")
    Do pResponse.SetValueAt("MSA|AE|"_pRequest.GetValueAt("MSH:10")_"|No Destination","MSA")
    Do pResponse.%Save()
    Quit $$$OK
}

This is obviously not robust code, but it does generate a NACK as a response object for every message sent to it, and if the BP is configured to forward responses from the Production BO created based on this, you'll get what you're looking for.

I think you really only needed to log out and back in again; at least that worked for me.

I created a new user with the %Developer role and verified that the class could be debugged successfully. I then added the %SecureBreak role to that user and encountered an issue similar, but not identical to the one reported by @Rueben Van Mol and @Donna Goodall:

<COMMAND>zDebugStub+30^%Debugger.System.1
Invalid debugger target: ##class(Blue.App.Handler.Absolut).TestConnection()
Target has exited debugger

I've copied your class into my local environment and am not getting any errors using the Studio debugger.

Cache for Windows (x86-64) 2018.1.2 (Build 309U) Mon Mar 4 2019 15:05:44 EST [HealthShare Modules:Core:15.032.9020 + Linkage Engine:15.032.9020]

Class Blue.App.Handler.Absolut Extends %RegisteredObject
{

ClassMethod TestConnection()
{
    w "ok"
    q
}

}

Debugger executing '##class(Blue.App.Handler.Absolut).TestConnection()'
Executing ##class(Blue.App.Handler.Absolut).TestConnection()
ok
Program has terminated.
Target has exited debugger

You're welcome, but the best way to thank me is to click the "Accepted Answer" button