Unfortunately, long strings can't be 3GB, but rather almost 3.5MB. For any sane usage of JSON this should be enough, but I've seen REST APIs where e.g. PDF streams are returned in base64-encoded JSON properties, that come uncomfortably close to that size.

It would be really nice if the %DynamicObject class added support for streams to deal with these large payloads!

It appears to be enabled when I try here, but I haven't used recordmaps much so I don't have one fully configured. I see another setting for the encoding in the record map properties itself; perhaps this is where things should be configured? (That would also explain why the adapter setting is disabled: you want to configure this only once.)

This datatype is not present in (currently latest) Caché 2017.2; it appears to be IRIS-only. That rather limits its usefullness. Besides, what is the performance of a datatype, and where is that a bottleneck?

Nice, I didn't know this. The IRIS docs appear broken at the moment, but this is documented here.

That link works. But if I search with Google (or DuckDuckGo), the first link that comes up for me appears to point to the proper page, but opening it loads a page about  SOAP Session Management. Many other links from Google end up on that page as well. The key in the docbook URL is ITECHREF_macro, that looks ok, so it seems the ISC docs are broken somehow.

Thanks for that, Evgeny, that does clear up things a bit. I hope Luca responds as well about the Quiesce... and SetMonitorState calls. I get the impression that things relating to creating containers are still changing rapidly. I do find the backslash-escaped multiline commands annoyingly ugly; your post above made that a bit better, compared to what was there before. (I'm hoping some of the ugly boilerplate will be delt with by ISC "inside" the container eventually.) I'm going to play around with your template a bit when I get the time!

I have enabled and used that feature in older versions as well; it is really useful. I have a PuTTY setup with a key pair that starts the IRIS terminal in docker on a remote machine, without any password, but still safe. (I wanted to use my regular account name as well, so I had to do some additional setup in the container, but the principle remains the same.)

Anyway, that explains why there's no need for a password anymore, thanks!

By the way, I have not een an announcement that 2019.3 became an official release, did I miss something? (I also see no Studio for 2019.3, and the 2019.4 preview Studio download doesn't work.)

This should have been the accepted answer. :) It is more important for code to be easy to read than for it to be easy to write.

I don't know if try/catch is slow, and I don't care. I don't use it because it is too wordy to handle errors exactly where they occur. It encourages code like in your example, where the code in methods is wrapped entirely in a try/catch block. You say the error object has all the information, but I disagree. It has some low-level information, but often lacks the context I need to determine what the problem is.

My preferred way of handling %Status errors is to add a %Status in front of it with more details of what happened when the error occurred, and return this to the caller. Somewhere up the call chain something will then handle the problem, e.g. add something to the Ensemble event log. This is such a standard way of working for me that I created a macro specifically for prefixing the new status information.

For errors that "raise" I also prefer $ZTrap+$ZError; I don't see the added value of try/catch here either.

Thanks, but a terminal command (requiring you to install the preview release) is not what I call documentation. But I did install it. To give an example of what the "Help()" gives me:

Help(method)
     Write out a list of the methods of this object to the console.
addToPath(path)
     <p>
createServer(serverDef)
     Create a new server.  This function requires the "%Admin_Manage" resource.

Interestingly, on the local installed preview, the class documentation does show the %SYSTEM.external class (with ever so slightly more information, btw.). I really hope that this lack of documentation is fixed before release, because as it is now, it is unusable.

Regard,
Gertjan.

Actually, on closer examination, it appears that in your example the problem is that the Continue is inside the Scope. If you move it outside the Scope, the problem doesn't occur (as you noted). The cause is that the fault handler that was pushed on the stack for the Scope is not removed, because the Scope is not exited "normally". Therefore, each iteration adds a fault handler to the stack that is never removed.

Having one or more scopes in a loop is a perfectly normal thing to do, if you want fine-grained error handling and/or recovery. I have just done some tests, and they work perfectly. If "best practice" dictates that this should not be done, "best practice" is wrong. A Continue inside a Scope, however, is never needed (even if perhaps convenient sometimes).

Unfortunately, I don't remember exactly what I did when I ran into my handler stack issue (it's been a while). Perhaps I also did a Continue inside a Scope. In that case, it was a bug on my part.

Perhaps this can be better documented? The description of the limitation you quoted above is rather vague. Even better would be if the compiler recognized this construct, and removed as many fault handlers from the stack as were pushed on it, when it encounters a Continue inside a Scope in a loop.

Just a quick response to your "topic for a different discussion", as it is relevant in this one. A Scope inside the loop allows one to examine the exact error, and if it is not fatal, decide to handle/ignore it and continue with the next iteration. A Scope outside the loop makes this a lot harder.

What BPL structure shows the problem solution most clearly depends on the problem and sometimes, as you note, on personal preference. It is therefore important to specify exactly which conditions are not supported, rather than "certain conditions". This allows the programmer to choose the easiest and/or clearest solution path, and not have to worry about things breaking if iterations exceed a certain (unspecified) number.

To purposefully withhold that information, as you suggest the documentation does, is saddening.

You can check whether you still have licenses available in the management portal: System Operation -> License Usage. If Current License Units Used equals License Units Authorized, web terminal can't allocate a new license, which it does seem to need. If not, yours is a different problem.