New post
AllAccepted answers
Dmitry Maslennikov · Jan 1, 2021

So, company policy forces to keep all the source code only in Caché? You can install own source control server, even GitHub. It will be completely your own server anywhere you will decide. With no ability to connect from outside if you would need it.

So, yes, I still sure, not a problem at all. 
I have been worked in company with two contours, one is for development with no access to internet, completely isolated. And another network for outside world. And we had to use two PCs, for our work. And we anyway we were able to use source control

Dmitry Maslennikov · Dec 16, 2020

InterSystems have changed SuperServer port in a few latest builds, back to 1972. So, just replacing 51773 with 1972, should work.

You can use docker inspect 

docker inspect containers.intersystems.com/intersystems/iris:2020.4.0.524.0

Will outputs something like this

.....
            "ExposedPorts": {
                "1972/tcp": {},
                "2188/tcp": {},
                "52773/tcp": {},
                "53773/tcp": {},
                "54773/tcp": {}
            },
.....
            "Labels": {
                "com.intersystems.adhoc-info": "",
                "com.intersystems.platform-version": "2020.4.0.524.0",
                "com.intersystems.ports.default.arbiter": "2188",
                "com.intersystems.ports.default.license-server": "4002",
                "com.intersystems.ports.default.superserver": "1972",
                "com.intersystems.ports.default.webserver": "52773",
                "com.intersystems.ports.default.xdbc": "53773",
                "com.intersystems.product-name": "IRIS",
                "com.intersystems.product-platform": "dockerubuntux64",
                "com.intersystems.product-timestamp": "Thu Oct 22 2020 13:02:16 EDT",
                "com.intersystems.product-timestamp.iso8601": "2020-10-22T17:02:16Z",
                "maintainer": "InterSystems Worldwide Response Center <support@intersystems.com>",
                "org.opencontainers.image.created": "2020-10-22T19:32:32Z",
                "org.opencontainers.image.documentation": "https://docs.intersystems.com/",
                "org.opencontainers.image.title": "intersystems/iris",
                "org.opencontainers.image.vendor": "InterSystems",
                "org.opencontainers.image.version": "2020.4.0.524.0-0"
            }

I've just left, only interesting lines in your case. Where you can find, which ports are declared as exposed in the image, and labels, which declares available ports in the image.

Access directly to the label

$ docker inspect containers.intersystems.com/intersystems/iris:2020.4.0.524.0 \
  --format '{{ index .Config.Labels "com.intersystems.ports.default.superserver" }}'                                                                        
1972
Dmitry Maslennikov · Dec 10, 2020

Those tools already have some expertise in that area. Yeah, they may have some difficulties with InterSystems IRIS, may not understand some of the features of InterSystems SQL language, and so on. DBeaver, for instance, is an open-source project and can be improved by anybody. 

But I'm not sure that it's a good idea to invest so much time in implementing something, which already available and in some cases for free.

Having too many tools out of the box, not so good idea, it will not mean that all of those tools will have enough quality. 

So, in this case, I would focus development on improving existing tools, in better support for InterSystems products. It will take less time, with a bigger profit (at least InterSystems will be noticeable not only for current InterSystems users).

Dmitry Maslennikov · Dec 9, 2020

First of all, it's not a common case for any code editor, and for sure VSCode is not an exception. What are you talking about is kind of deployment process. And have to be solved in that manner. You have to produce some kind of version of your application and install it. It's how it's supposed to be.

At the moment with VSCode, you can export any source code from the server, to get all the classes locally. And import those files as a folder. But it may not work as you would expect, and may cause some compiling issues. This case will not be changed in the future, as completely make no sense to have in the Editor.

Dmitry Maslennikov · Dec 8, 2020

The issue not in Caché, it’s in Windows, which just not allows any interaction from services. You can enable it by editing service.

But in your case I would look into other ways for interaction. Server means, that in 99% of time it works alone with no people sitting behind the screen, even it should not have a screen at all. So, in normal case it’s very small chance that anybody will see your message and press ok.

If you need a suggestion on how would it better, please describe what’s exactly you are trying to achieve.

Dmitry Maslennikov · Dec 8, 2020

Unfortunately, docker-compose does not have any way, on how to limit cpus during build. While it's possible for deploy. The only way to do it in your case, is to build image manually with specified limitation.

docker build -t someimagename --cpuset-cpus 0 .

and then just add this image name to docker-compose.yml, you can keep the build section, it will not be used if you desired image already produced.

services:
  iris:
    image: someimagename
    cpuset: "0-7"