Is the file you are editing in IRISLIB or some other Read-Only database?  If so, use the System Management Portal (SMP) to turn off the database Read-Only option.

I am not sure exactly what you want to do.  Is check1 just an ordinary string, or might it sometimes be a string that starts with a number (like a %Status variable)?

The unary plus operator (+) turns a string operand into a number.  If the string starts with the syntax of a number then +string returns that number and ignores characters in the string following the numeric syntax.  If the string does not start with a number (this includes the empty string) then +string returns 0.  It is possible for +string to signal <MAXNUMBER> if the characters at the beginning of string are too large for conversion to the computational numbers supported by ObjectScript.

You could try
  ret:+check1 check1
which would return check1 only if it were a non-empty string that starts with a non-zero number.

If you want to return a string value that could be tested as a boolean that you have to append "1" to the front of the string if +string=0 is true.

The Class Reference pages for IRIS, available in any IRIS installation, describe all the classes installed in the installation.  The Class Reference for the %Regex.Matcher class documents that the %Regex.Matcher class comes from the International Components for Unicode (ICU). The ICU maintains web pages at https://icu.unicode.org .  The class reference documentation also contains the following statement for ICU documentation specific to the IRIS %Regex:

{quote}The definition and features of the ICU regular expression package can be found in https://unicode-org.github.io/icu/userguide/strings/regexp.html .{quote}

Additional documentation on the Unicode Regex package specific to how it interacts with the Unicode character set can be found at https://www.unicode.org/reports/tr18/ .

A quick comment on performance.  A TRY ... CATCH is very efficient at run time if no exception occurs.  The only extra code that is executed is a jump at the at end of the TRY block to go around the CATCH block.  However, TRY ... CATCH is slower than using the %ZTRAP when an execption does occur.  At compile time TRY ... CATCH blocks build tables that include program counters that describe which object code locations are in each TRY block and where the corresponding CATCH block begins.  When an error is signaled (or THROWn) at run time, it is necessary to scan the frame stack searching the compile-time generated TRY ... CATCH tables to find the CATCH location to go to after popping the intermediate stack frames.  If there are no TRY ... CATCH blocks involved then it is usually faster to just jump to the most recent setting of the $ZTRAP variable.

When exceptions are "exceptional"  then TRY ... CATCH is most efficient since it avoids pushing $ZTRAP value in preparation for handling an exception and it also avoids popping the $ZTRAP value when the exception does not occur.  If exceptions are part of a usual, successful, and often executed code path then it might be better to use $ZTRAP to catch those frequently executed signals.

The %DynamicAbstractObject (%DAO) subclasses, including the %DynamicArray and %DynamicObject classes, provide the best way to read/send JSON representation into/out-of IRIS databases.

The %FromJSON method can create a tree of %DAO objects from external JSON representation.  Then elements of %DAO data can be read or accessed using ObjectScript property syntax and using methods like %Get and %GetIterator.

Data inside an IRIS database can be used to build a tree of %DAO objects by using the ObjectScript JSON constructor syntax, property assignment statements and using methods like %Set and %Push.  If all you do is store values into previously undefined elements of a %DAO object then the performance is usually quite good.  Then that %DAO tree can be turned into JSON representation using the %ToJSON method.

It is not recommended that data in a tree of %DAO objects be extensively and repetitively modified/updated by the %Set method or by other ways that can modify data in a %DAO.  This is especially true if you are repetitively changing the size of data elements.  In such cases, the data in %DAO objects should be extracted and converted to some other optimized database structure.  Often this can be Relational DataBase access if a mix of rectangular arrays provides the desirable access.  It can be a %Stream if sequential access is needed.  If a number of data elements are to be searched then columnar vectors can be used.  IRIS can supply all these other access methods by layering them on top of ObjectScript multi-dimensional arrays.  The IRIS multi-dimensional arrays (both global and local) provide the best tradeoffs across a large variety of differently ordered read/write/update/modification operations.

If you have data in a %DAO tree and you need to make small or infrequent modifications of the data then it is acceptable to leave it in %DAO representation.  You can also make repetitive reads of %DAO data without needing to convert to some other representation.  But otherwise, %DAO objects are best limited to moving data into and out-of JSON representation.

Assuming  that response.message_code is part of an ObjectScript expression then you want to evaluate response."message_code" because _ is an ObjectScript operator so you must quote "message_code" to change it into a method or property name.  Otherwise, _ is the string concatenation operator so the value of response.message will be concatenated with the value of code.

I agree that LOG^%ETN, and ^%ETN as a process terminating trap routine, are the best way to log problems.  But we should also mention that DO ^%ERN is the utility that will dump the data that LOG^%ETN places in the ^ERRORS multi-dim global.  That dump includes state information, a complete call-stack dump, a list of all active local variables at each stack level, and in recent IRIS releases, it also includes a dump of all Class Objects with an oref active in memory.  This is a lot of information for each ^ERRORS entry so you might not want to be over-enthusiastic with your calls on LOG^%ETN.

We need to see more of your code to see what is truly happening.  The routine method call Do obj.%Set("data",pStream,"stream>base64") should have no problem providing your system has enough memory to construct entire 'obj' Dynamic Object in your process memory.  Your system will want to avoid having many large Dynamic Objects in memory at the same time.  If the system runs out memory for all the active processes then the operating system will usually start aborting processes randomly until the operating system decides it now has enough free memory to continue execution.

Calling %Set(,,) to read JSON text from a very large %Stream should only use moderate size buffers on the string stack.  If a call on %Set(,,) writing from a %Stream generates a <STRINGSTACK> signal then that should be reported to InterSystems as a bug.

However, your reply mentions the %ToJSON() function method call.  Calling %ToJSON as a function will place the result on the String Stack so it is possible such a function call could signal a <STRINGSTACK> error although if the %ToJSON() function call appears in a very simple expression then I would expect a <MAXSTRING> signal instead of a <STRINGSTACK> signal.

Calling %ToJSON() or %ToJSON(outstrm) as a routine method call in a DO statement should not get either a <STRINGSTACK> or a <MAXSTRING> signal since the result is not going to an ObjectScript string value.

The %FromJSONFile(file) method does not take a %File object as an argument but instead takes a string containing the name of file.  You need to replace

set newObject = {}.%FromJSONFile(file)

with one of

set newObject = {}.%FromJSONFile("/tmp/longObjectFile.txt")
set newObject = {}.%FromJSON(file)

Originally, %FromJSON(input) would accept the 'input' argument as a %File object, a %Stream object, a JSON text string or a filename text string.  However, accepting an argument string as either JSON or a filename was considered to be security issue because a malicious user could be requested to enter a json-string but, being malicious, the user would instead enter a filename-string, or vice-versa.  As a result %FromJSON no longer accepts filename strings while %FromJSONFile only accepts filename strings.

No longer an issue, but it would be possible that legal VMS filename syntax could also be legal JSON text string syntax and such an argument string might be ambiguous on a VMS system.  But IRIS no longer supports VMS and Caché for VMS did not support Dynamic Objects.

Most of the ObjectScript examples above (but not the Python example) take O(n**2) time (i.e., quadratic time) where 'n' is number of values in X.  This happens because the $PIECE(X,",",i) starts searching from the beginning of the string or because shortening the string X with

set x=$p(x,",",2,*)

will copy the string 'x' multiple times with the first element deleted before each copy.

The ObjectScript example from Timo Lindenschmid  using $LISTNEXT takes O(n) time (linear time).  This can be important if $L(X,",") is 1000 or more because such a list with 1000 elements will require about 500,000 scans of "," characters or about 500,000 copies of string characters.

Rich Taylor's Python example should also take linear time.

Another solution would be to build a %DynamicArray object and then iterate through its contents.

Finally, you could build a multi-dim ObjectScript array and iterate through the subscripts with $ORDER.  This is method closest to using standard MUMPS/ANSI M/ObjectScript features.

The third argument to %GetNext is not a string value.  It is a variable passed by reference:  iterator.%GetNext(.key,.value,.type).  When this returns then the variable type will contain a string value like “string”, “number”,”object”, etc.  If type contains “string” and $isobject(value) is true then value is a %Stream object containing your long string.

If your method can handle %Stream data then you can copy the large string piece-by-piece into an appropriate %Stream.  If your method cannot handle %Stream data then you must modify it to test for a parameter that is a %Stream object instead of a string and then process that data by calling the stream.Read() method to scan through the %Stream.

A few built-in methods do have this capability.  For example, the %FromJSON(arg) method in the %DynamicAbstractObject class will accept 'arg' being either a string or a %Stream object.

Well, my DO command suggestion won't work in ObjectScript because ObjectScript has extended the MUMPS DO command to accept syntax for the
   DO { code } WHILE expr,expr,...
statement.  The code block in the DO-WHILE extension does not assume the code block opens a new variable scope.

However, like most languages designed in the 1950s and 1960s, (including FORTRAN, BASIC and PL/I, but not C) MUMPS does not have reserved words.  Therefore, any newly added command can start with a new command word.  So we could have BLOCK { code } or SCOPE { code } as new commands that open a new variable scope.  We might be able to find a better command word than BLOCK or SCOPE.  We could even consider NEW { code }, although it might be considered confusing having an additional NEW command (one with a curly brace code block along with one with no arguments, one with list of argument names and one with a list of names surrounded by a pair of round braces).

I always wanted to extend argumentless  DO so that you could get a new scope without needing the fairly ugly dot-indentation lines.  Then you write something like

Do {
   New $roles
   Set $roles=""
   If ($extract($roles,1,$length("%All"))="%All") Set tHaveAllRole = 1
}

You could even write the whole thing on one line like

Do {New $roles  Set $roles=""  If ($extract($roles,1,$length("%All"))="%All")  Set tHaveAllRole = 1}