You have a view command in Blocks.WebSocket.ReadBlocks that looks like this:

View aBlockId

It's a good practice to always put a sanity check around view commands, something like:

if ((aBlockId>0)&&(aBlockId\1=aBlockId))
{ view aBlockId }
else
{ <error handling> }

That check makes sure it's a whole number, and a positive number.  If you try to pass something to VIEW that's not a whole number, you'll get an error.  More problematically, if you pass a whole negative number to it you'll be writing to the database instead of reading from it.  Doing that when you meant to read can cause database corruption and other integrity issues.

In this case, aBlockId is passed into the function, so all that has to happen is the caller passes in a bad value that isn't 0.  You could expand the quit:aBlockId=0 0 check you have earlier in the function to achieve the same thing, but I think it's better to make a habit of always wrapping the VIEW command in this kind of check, or always using a macro that does the check - it makes it easier to review the code and make sure there's no possibility of it doing something harmful.

%SYS.System.GetNodeName() looks like the replacement for that $zu function.

Correction - %SYS.System.GetNodeName() is the replacement for $zu(110) which you were using in the initial version of this post.  The replacement for $zu(67,12) looks like it could be either %SYS.ProcessQuery.ClientNodeName or %SYSTEM.Process.ClientNodeName().  The full list of replacement functions is at http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...