We're looking to create a quick and simple test to see if all firewalls are open on 1972 between a linux based web server VM and a VM running InterSystems IRIS. Does anyone have any ideas for a quick command that can be run from UNIX console that will provide confirmation that traffic is able to get to 1972 on an IRIS machine?

BTW - I don't think it makes any difference but the IRIS machine is running Windows

0 16
0 195

I am looking into creating a ZSTOP as you probably have seen from my previous posts, is there a way to capture the type of shutdown that occurred? So say if there was an unknown hardware failure (forced), vs a user shutdown? Mainly looking for user or system shutdown when we force another destination to become the primary in the mirror. So if a user shutdown the production to do.,... Task A, Task B etc..

Thanks

Scott

0 3
0 230

To prepare a migration to IRIS I use Docker images.
The (aged) application is built around Caché Terminal
And on Windows, IRIS uses the same ctelnetd.exe as Caché.

In my Docker installation, Telnet Settings are just grayed out in SMP.
and my Terminal can't 'connect.
Port mapping is OK and verified with TCP

Working from the console in Docker with the whole set of ESC and
screen formatting is not acceptable.
We tried WebTerminal but there is just no Partition behind as in Terminal.

2 4
0 111

I am working on setting up our Failover techniques as we move to a Mirror Environment with a Arbiter, 2 Failover Nodes, and a Async (DR) Node. There are some system commands that I would like to call when the Mirror moves, and I am working on a ZMIRROR routine for that, but I also wanted to create an additional step if we wanted to manually shutdown and for the Mirror to move. So I was looking at using ZSTOP to call a couple of different items while shutting down, while the documentation has an example a couple of questions come to mind about using ZSTOP.

0 3
0 167

We have messages that are in a queued state for various reasons and when we do a manual shutdown of the instance, they are moved to a Suspended state. I thought I saw in the documentation somewhere a setting to make sure these messages stay in a queued state and not suspend them. Can someone confirm and point me in the correct location for that documentation, as I am trying to ensure that if we do have to manually shutdown a instance, someone doesn't have to remember to go back in and check for suspended messages and resubmit them?

Thanks

0 2
0 120