The gateway server is mainly taking care of Logging and tracing using 53773 as a backward link.
So your network experts are right.


here is the example Defining a JDBC Connection URL


where the parameters are defined as follows:

  • host — IP address or Fully Qualified Domain Name (FQDN). For example, both and localhost indicate the local machine.
  • port — TCP port number on which the InterSystems IRIS SuperServer is listening. The default is 51773 (or the first available number higher than that if more than one instance of InterSystems IRIS is installed — see DefaultPort in the Configuration Parameter File Reference).
  • namespace — InterSystems IRIS namespace to be accessed.

AHH! that sounds quite different.

First is your super server port really 53773 ?
Default is 51773.  While 53773 might be a gateway port for reverse connection. 
you can check in SMP  System > Configuration > Memory and Startup  

I suspect telnet as a protocol might be blocked by some firewall by principle.
from a terminal prompt in IRIS  you might try this:

USER>set tcp="|TCP|7000"
USER>open tcp:(:7000) use tcp read req#15

So you create a TCP listener on port 7000 hanging around
Then try to connect from an external server by telnet to port 7000 on your server 
As soon as you send 15 or more characters the READ will complete and you see the content in variable req  

As you describe I assume this will fail. Indicating that some firewalls or similar blocks access.
Most likely the port is blocked.

In addition netstat -a from system prompt

or user>$netstat -a  from IRIS terminal  shows ALL listeners on your system

It's not clear to me what you try:

" customers can connect to IRIS remotely using JDBC and not ODBC...."

So they need the related Java-Libraries to connect.   see Establishing JDBC Connections

While the setting in your jpg. relate to the SQL-JDBC Gateway that allows access to other DBs over JDBC.
You have also a JAVA gateway to run java out of IRIS See Using the Java Gateway.

An index on  reg.mnr and bar.invnum  will accelerate this.

That's a general problem of a web interface like this.
You start a query but it isn't finished before your fall into a browser timeout.

An easy workaround:

Start a terminal session (terminals don't know about timeout)
and from prompt run SQl.Shell

or for a multi-line statement just start with an empty line and run with GO

It will wait forever until completed

I'm not aware that this is available at SQL / DDL level 

You can set the default collation for all globals in a database.

or specific for an individual global before using it. 

The available collations have to be added here

I see 4 critical points to check:

  • if customerID is autogenerated or calculated you can't  insert to it or update it
  • if customerName has some constraints like UNIQUE or fails some other formal checking
  • if the (existing) record is locked by some application running in parallel
  • if some access rights block you