This is how Durable %SYS works, when it's initialized, it copies everything to the durable folder, including your db in mgr directory. And you can prevent it, by creating this database, just somewhere else.

Caché will not get support for M1, and so, I think no reasons to wait for an ODBC driver for M1 too

It's not a big issue, to make it work. Just keep in mind that both containers, with SAM and monitored system, have to be in the same docker's network. If you run both images in with docker-compose, they by default will get the same network, so, in most cases, you may use IRIS service's name from docker-compose.yml as a hostname, and it will be able to connect to it internally inside that network.

If you need access from dockerized SAM to a dockerized IRIS, both working in different networks, you have to publish ports for IRIS, so, it should be available from the host, but from the docker, your SAM has to know the host's address and host.docker.internal is a way, to give it to him. And port should be the same as published when docker container is running.

When docker container is started with -p param, which says how to publish the port, possible to say, which IP to select, or select all  for instance -p 0.0.0.0:52273:52273

docker ps, may help with understanding how the container is available

8d8977f9d5f8   intersystemsdc/iris-community:preview                          "/tini -- /iris-main…"   6 days ago       Up 3 days (healthy)       0.0.0.0:1972->1972/tcp, 2188/tcp, 53773/tcp, 0.0.0.0:52773->52773/tcp, 54773/tcp                           iris

if it shows something like 127.0.0.1:52773->52773, it will only be available as localhost or 127.0.0.1 and will not be accessible from another container and network, because of host.docker.internal will refer to another ip

Could you explain, how you running all the parts?

There is a community edition license embedded, and you can use it.

Globals are stored in the database and they are limited only by the size of that database.

I'm not sure if the size of the database has any limits, at all, but at least what I know, is that I have database files with up to 10 terabytes per one file. And the only reason is that it's not large than that, we split the data into smaller files due to external reasons, such as filesystems, and just having smaller files makes it easier to operate as a file.

Is it works on the same host or not? Server and odbc  client

$system.OBJ.OpenId(class,id)

$classmethod(class,”%OpenId”,id)

When you have ISFS configured to multiple namespaces, you can just use copy-paste ability to copy files between isfs folder, or with using real folder.

Link to documentation

Local way, is actually how it was designed by default, and how you'll get the best experience.

What issues did you face? 

In short how to start using it.

• You need to configure access to your server through parameters under "objectscript.conn"
• Use your local code, if you already have it, or export code from the server, once you are connected
• Edit and save files as a usual file, will save it on the server and compile it, in case of any compilation issues it will notify you about it.

You have to look at grade documentation. And it will be something like this. it says, to look at libs folder for jar files, usually it only uses some remote repositories like maven central

repositories {
    flatDir {
        dirs 'libs'
    }
}

Do not use %ZEN, it’s deprecated. There is Native JSON support, and %JSON.Adaptor, use this instead. Any output with write command will produce this error.