with 

set tSc AuthToken.Post("/webservices/Void")

you miss some content to POST and get

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Header/>
    <soapenv:Body>
        <soapenv:Fault>
            <faultcode>Client</faultcode>
            <faultstring>An exception has been raised as a result of client data.</faultstring>
            <detail>
                <err:Errors xmlns:err="http://www.ups.com/schema/xpci/1.0/error">
                    <err:ErrorDetail>
                        <err:Severity>Hard</err:Severity>
                        <err:PrimaryErrorCode>
                            <err:Code>10001</err:Code>
                            <err:Description>The XML document is not well formed</err:Description>
                            <err:Digest>Unexpected element: CDATA</err:Digest>
                        </err:PrimaryErrorCode>
                        <err:Location/>
                    </err:ErrorDetail>
                </err:Errors>
            </detail>
        </soapenv:Fault>
    </soapenv:Body>
</soapenv:Envelope>

use instead

set tSc AuthToken.Get("/webservices/Void")

and receive

<HTML>
<HEAD><TITLE>UPS Online Tools VoidWS</TITLE></HEAD>
<BODY><H2>
Service Name: VoidWS<br>
Remote User: null<br>
Server Port: 443<br>
Server Name: wwwcie.ups.com<br>
Servlet Path: /Void<br>
</H2>
</BODY></HTML>

just run $System.OBJ.Export() for your Global and hand over the result to your CVS.

USER>s sc=$system.OBJ.Export("^rcc.GBL","exportTest.txt",,.error,"UTF8")
 
Exportieren in XML gestartet am 04/01/2018 10:25:26
Exportiere Global: ^rcc

the result is a nice XML structure

and $system.OBJ.Import()  reloads it  

The extension  .GBL is the important thing

http://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?P...

Update: 

Blocks.Router uses $toJSONFormat() {CR/LF formatedOutput }
this hidden function hasn't been ported. replacement with %ToJSON()  does it as well.
So TREE view works nice.

Map view gets no content (and no colored dots  crying ).
Reason:  Block Count=0 and also %Fill -> nothing to display (makes sense somehow). 
This is also with the original classes in 2016.1.4 ;
Looks like an privilege issue.

You are missing the point.

12345 is the port used by the cache DB server   (default=1972) of your instance.
internally there is a mapping between the logical NAMESPACE and the physical disk directory and that NAMESPACE is used in connection string.
if your namespace is called DB then  you have to use 

jdbc:Cache://localhost:12345/DB

But if you just have the directory .../cache/db/cache.dat  you can't say what NAMESPACE this is
You have to know your Caché configuration.

Some reading on Caché configuration may give you background information
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

OK. I understand.
- I doubt if a Linux distribution of Caché contains any Windows mechanics. ( to be checked with WRC )
- on the other hand I don't believe it's possible or make sense  to run Caché Win distribution in a Win-Shell ...
So suggested workaround:
Have a VM (or small machine) with Windows +Caché and connect via ECP or similar (REST, WebService, JDBC, ...)  to your main Caché instance on Linux. 

OR:

Wrap some C# around your DLL on a Windows box and present it as a WebService that you call from Linux.

Hi Jeffrey,

Your descriptions matches pretty well what is titled in Ensemble as "Workflow"
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=...

It uses specialized Request and Response messages that are designed to allow a significant time gap in between.
It's originally designed for human interactions but to my understanding it implements exactly your "sideline".
And human interaction is just there to show it may take long time to get a reply.
There is also an example in ENSDEMO  Demo.Workflow.Production  ​

 HTH,

Robert