That's in fact happening by separating Globals-DB from Routine-DB in the namespace definition.
Those globals are visible in any DB but they are used only for RoutineDB with a kind of implicit routine mapping.  (ages old and implemented shortly after "Big Bang") 
Once the Routine-DB is clean and isolated just copy the full DB 
or use $system.OBJ.Export(....)

As example of this implicit mapping a view of my ^ROUTINE in namespace DEMO

Thank you @Herman Slagman !
I like your suggestion and would fully support it if ISC would take that turn.
You mentioned ignorance and you are right. I'm full with you.
Though I still see another more dangerous hurdle to pass:
Understanding the concept. Applying the concept. Teaching the concept.
I just fear there might not be enough qualified developers available to execute it.
Seeing the actual situation on my side of the globe I wouldn't expect to find enough experts.  

  1. Whatever you do it affects the operational machine as you have to read through the whole Table/Global
  2. For Table it can be a simple SELECT * FROM TABLE  with the option to select columns of interest
  3. For Global  use $system.OBJ.Export(<globalname>.GBL,<filename>)  as XML.

 Of course, if you have a Shadow instance of your operational machine you can do it there and avoid the load on the primary machine.
Eventually, you can run there all analyses without export at all.

Thanks for the input. (I was waiting for it)
If someone goes for speed I'd suggest  C or Assembly Language That's where ultimate speed lives.
As long as speed is available in the cloud for a few $$$ more. It's only interesting by principles not in reality.
The key  - in my opinion - is to break the chains of a rarely known scripting language compared to others.

On what operating system do you run this repo ?
Your ERROR message looks like coming from Windows [backslash] (No directory \home\....)
BUT the whole code seems to be written just for Linux/ Docker images

It is nowhere mentioned as a prerequisite. Might be implicit to.
>>>     "you’ll need the InterSystems Sandbox" 
I never heard of, never used it.

to get a clearer picture of the requirements it is essential to understand
how the connection operates:

  1. connection is established and messages are exchanged leaving the connection open
  2. connection is established, the message is sent, the connection is closed

It's evident that the behaviors are different  on both ends 
for #1 you start with a Listener and keep it cyclic reading, eventually writing

for #2 you open the listener, receive something and close it
to send your message you need an open - write - close cycle.

both are possible but you have to know what your opponent expects and how it reacts.

The whole requirement is rather archaic. Sounds like a webserver without HTTP.
REST would be the better approach.

Finally, you may consider outplacing the whole connection management to Node.js
which is far better suited for such exercises. Eg: wrap incoming stream into REST