Please add more details, how did you try to do it, and $zversion of your instance. 

You can find answer on your question in the documentation.

It is not a problem for Caché, you use x86 and limitation from architecture.

You have to upgrade your server to 64bit, and then you may use even hundreds of gigabytes of memory.

Looks like, you don't know how this technology works.

The server will send content after all content is ready to send. Browser shows page, just after loading all the page, or partially, if this page is too big.

To do what you want, you should have some code on client side, which will ask the server for the new lines by Ajax. Or with WebSocket, just get new lines from the server. But it means that process which generates such logs, should be different to the session process.

In current stage, we do not have any Caché code, yet. But I don't see any troubles here. You may use base Ensemble image, and run it on GitLab environment, or on your own server, via gitlab-runner and preinstalled Ensemble. With GitLab-CI, possible lots of different ways.

Even more interesting that, GitLab has their own docker registry. And you can even build your own image for ci with ci.

We build Ensemble container. You can look at archive of my project ensemble.zip . Simple image with Ensemble, without Samples and Docbook databases with minimal security.

There are not such methods, we only have function which converts delimited string to $listbuild format and back. And you can do it in this way, without any looping, but only if you already know how many items you have.

USER>set string="a,b,c,d,e,f"

USER>set list=$lfs(string,",")

USER>zw list
list=$lb("a","b","c","d","e","f")

USER>set $lb(array(0),array(1),array(2),array(3),array(4),array(5))=list

USER>zw array
array(0)="a"
array(1)="b"
array(2)="c"
array(3)="d"
array(4)="e"
array(5)="f"

What do you want to fix? Locked access or change security level?

Mostly when you run some server application inside a container, it means that no needs any changes of settings, while this container is up because all that changes may disappear after restart container form a new image.

I would recommend changing security level in the installation process. You can do it with some environment variables described in the documentation. Just add this lines in the Dockerfile before cinstall_silent command

ENV ISC_PACKAGE_INITIAL_SECURITY="Locked Down" \
    ISC_PACKAGE_USER_PASSWORD="secretpassword"

And your installation will be secured.

Read more about initial security settings in the documentation.

Sure, leading zero, so, fixed code.

set hashHex="" for i=1:1:$l(hash) set hashHex=hashHex_$translate($justify($zhex($a(hash,i)),2)," ","0")

The difference only in output format. InterSystems returns just string of bytes, while online generator returns hex codes for that bytes, which is much better for reading by human. So,  you may quickly check it with command zzdump. And you may notice, that zzdump shows the same hash you got from online generator.

USER>set hash=$system.Encryption.SHAHash(512,"test")

USER>zzdump hash

0000: EE 26 B0 DD 4A F7 E7 49 AA 1A 8E E3 C1 0A E9 92         î&°ÝJ÷çIª..ãÁ.é.
0010: 3F 61 89 80 77 2E 47 3F 88 19 A5 D4 94 0E 0D B2         ?a..w.G?..¥Ô...²
0020: 7A C1 85 F8 A0 E1 D5 F8 4F 88 BC 88 7F D6 7B 14         zÁ.ø áÕøO.¼..Ö{.
0030: 37 32 C3 04 CC 5F A9 AD 8E 6F 57 F5 00 28 A8 FF         72Ã.Ì_©­.oWõ.(¨ÿ

And this simple line of code, may help you to convert this hash to hex hash.

USER>set hashHex="" for i=1:1:$l(hash) set hashHex=hashHex_$zhex($a(hash,i))

USER>write hashHex
EE26B0DD4AF7E749AA1A8EE3C1AE9923F618980772E473F8819A5D494EDB27AC185F8A0E1D5F84F88BC887FD67B143732C34CC5FA9AD8E6F57F5028A8FF

USER>write $zconvert(hashHex,"L")
ee26b0dd4af7e749aa1a8ee3c1ae9923f618980772e473f8819a5d494edb27ac185f8a0e1d5f84f88bc887fd67b143732c34cc5fa9ad8e6f57f5028a8ff

In my experience such behavior I saw when we had so many writes to the disk, and write daemon queue only grown up.

In first I would launch mgstat tool from InterSystems. But it should be started before the freezing system, and for quite long time, with at least 5 seconds interval, better if it would be 1 second. Then you should look at some columns such as WDphase, PhyWrs, WDQsz.

What you should look for. 

• WDphase -  should not be all the time in the 8th phase.
• WDQsz - from time to time should fall to zero
• PhyWrs - may help to calculate a "real" speed of writing to the disk. And compare with expected speed.
• WDPass - time to time should be increased, if WD still at the same cycle so long time, it may cause a freezing system.