Why not to use
strace -p <pid>
where the process is serving terminal (W $J, run set ret=$zu(-100,...) )
or host process in interoperability infrastructure
to check what is wrong from point of view of syscalls.
A quite standard way to figure out what goes wrong.
terminal and service process has different uid,gid.
terminal uid,gid has of logged user
and user make sence have irisusr supplement group in order
to run iris session ok.
service process (in particular BusinessService) uid,gid has irisusr:irisusr.
unless uid and gid has no relationship and use different name.
gid name might be changed in installer, irisusr is 'fixed',
but it might be changed in /etc/passwd.
to know process uid,gid
ps -eo pid,uid,gid,args | grep irisdb
check dir access right from
/data/InterSystems/IRIS/mgr/TEST01CODE
and below.

For zip case, I would use command pipe and one parses output
in order to know the result of operation.

If ce/iris is started by ccontrol /iris start in systemd service context then it must to be stopped also in systemd context.
If one is used ccontrol/iris start directly there are consequences for system where init is systemd.
1 ce/iris processes are in cgroupv2 in user.slice hierarchy (more logical to have it in system.slice)
2 ce/iris processes are under systemd session and for example if /etc/systemd/logind.conf  KillUserProcesses=yes then after user logout and  user session destruction
sibling processes might get signal (default SIGTERM) and handler might do process exits.
Some ce/iris system daemons are terminated (mainly started by startup STU), some are not terminated (mainly control and those are forked from it).
Another thing is /etc/systemd/logind.conf  RemoveIPC=yes.
systemd might just remove ipc resources owned by cache instance resulting cache kernel is not working
correctly in very base stuff.
Shortly it is worth to reread man systemd-logind, man logind.conf, man loginctl.
Though systemd service wrapper for control/iris start is not quite consistent with direct use of ccontrol/iris start and systemd might lose correct service state but it never loses control on processes as being unix init process.
Direct usage of ccontrol/iris start|stop requires attention to logind.conf KillUserProcesses=no, RemoveIPC=no.
systemd service wrapper is worth to use as ccontrol/iris start|stop wrapper if system is managed by systemd.

I would use template variant.

cat /etc/systemd/system/isccache@.service

[Unit]
Description='isc cache'
After=network.target
#After=network-online.target

[Service]

# 1st way oneshot
Type=oneshot
RemainAfterExit=yes
# end of 1st way

# 2nd way forking
#PIDFile recommended but might be absent
# Type=forking
# end 2nd way 

ExecStart=ccontrol start %i
ExecStop=ccontrol stop %i quietly

[Install]
WantedBy=multi-user.target

<end>

examples
systemctl start isccache@201772B865
systemctl status isccache@201772B865

systemctl stop isccache@201772B865

systemctl enable isccache@201772B865
systemctl disable isccache@201772B865

if systemd ce/iris service state is wrong or ce/iris shutdown fails.
ccontrol force 201772B865
systemctl stop isccache@201772B865
now it is ok for 
systemctl start isccache@201772B865

ce=cache or ensemble

I tried windows open ssh server and I stopped to use it due to many glitches.
For some version it simply doesn't work  (connection failure) for others I got terminal problem  after some time of working in ssh session.
Yet another possible variant worth to try.
https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?K...
Other words you might try to use telnet protocol over tls.
I never tried it, but you might try since you are motivated to do it.
tls  for windows is expected to be robust.

Also I reported systemd bug
purpose 1 run cache/iris as systemd service by not root user using polkit jscript , user must be in cache/iris management group. It is ok.
purpose 2 use systemd-run to start|stop cache/iris by ccontrol/iris  consistent way with systemd where user in cache/iris
management group. It is not ok and subject of systemd bug. root works ok.
https://github.com/systemd/systemd/issues/17224

You will be happy even for /etc/systemd/logind.conf RemoveIPC=yes if cache installation uses owner=cachesys, group allowed start/stop cache - cachemgr. You might use either names you like instead of cachesys, cachemgr but 'cachesys' != cacheusr (in term of uid) It works even if cachesys uid > 1000 i.e. it is considered as non system process.