Thanks for the info about the evolution of the LIST functions.

I'm just a developer without any insight information into the internals of LIST functions and, as you wrote, "The changes were carefully done so that working programs that use functions of the form $LISTxxx, $Lx, and $LxS to manipulate $LIST strings will not notice the changes.", hence I do not saw any changes.
OK, there were some enhancements like adding $LV() and $LU() or a third argument to $LTS(), but those changes are not relevant for existing applications.

Regarding the speed gain by using (JSON)array instead of (JSON)object, yes you have right, the array variant is about 5% faster. I just didn't made a speed test for the new solution, the goal was to have a "legal solution" and not an all-time record.

Finally, I'll ask you, why are things like the internal format of $BIT() or $LB() unpublished?
For example, $LB() can't be such a big mystery because a simple ZZDUMP reveals the structure?

There are cases where this information would be (very) helpful. Just to name one, I have a particular case. 

I wrote a simple class, which uses $ZF()-callouts, so the customer can create (i.e. export) data into an excel file (including formatting and colors) as well as read (i.e. import) data from an excel file (again, from *.xls and *.xlsx). The class has methods to read/write individual cells or whole rows or whole columns.

To pass row- and column-data between the application and the callout module, I use $LB().

set exl=##class(%Zu.Library.Excel).%New()
...
// writing data
do exl.WriteNum(row,col,value,format)
do exl.WriteRow(row,data) // data is $lb(col1, col2, ...colN)
// reading
set value=exl.ReadNum(row,col)
set data=exl.ReadRow(row)	// data is $lb(col1, col2, ...colN)
...

To be able to write the corresponding callout module (Windows-DLL as well as Linux-SO), the information about the $LB() structure were esential.
This is just one example. Similar solutions were used for the PDF- and ZIP-callout modules too.
At least for the $LB() it shouldn't be such a big secret, and an official documentation would certainly make more happy customers. But it is not my decision, it must be decided by ISC.

From your JSON-String, someone stripped off two chars at the end: "}]"

So if you add those chars, everything will be OK

d ##class(%ZEN.Auxiliary.jsonProvider).%ConvertJSONToObject(JSONString3_"}]",,.list)
w list.GetAt(1).sensors.GetAt(1).jobGUID --> 0b955ee7-9a54-4b13-9af1-7019721faeab
 

I was told,  it's illegal to use data structure information, which doesn't were changed in the last 25 years (and after this many years, one could think to have the right given by "customary law" to use it), hence I decided for a more "legal" solution for the above problem - although this solution will work for IRIS (and recent Cache systems) only:

Class DC.Test Extends %RegisteredObject
{

/// Return TRUE if val contains a string
ClassMethod IsString2(val) As %Boolean
{
    quit {"a":(val)}.%GetTypeOf("a")="string"
}

/// Return TRUE if val contains a number (int, real or double)
ClassMethod IsNumber2(val) As %Boolean
{
    quit {"a":(val)}.%GetTypeOf("a")="number"
}

}

Oh, thanks for the hint, I'm aware of that. Actually one should remove the same characters as used in $locate():

if $locate($zstrip(data,"<w",",."), ...)

but the point is, to circumvent such problems, the rule number one in the electronic data processing is: you have to apply for check each and every input (at least) a formal check or you end up with problems like this. So the desired process should be:

read_data --> check_it --> proceed_if_OK_else_back_to_input

The same goes for data during an import process.

You are right, that's my fault. I didn't read the Notes, just the beginning of the challenge. Sorry.

The challenge talks about "...rearranging the letters ...", there is no restriction for the ASCII sequence, so this would not work with cyrillic character set :

CMOKBA  (fig tree, russian)
MOCKBA  (Moscow, capital city)

justmy2cents

One more test case:

set a="abbc", b="abcc"

I referred in his answer only the $replace() function without explicit pointing this out. I was upset about the ambiguous question, sorry.

Sergei Shutov's answer is correct. The question was, how to remove a specific character (in this case: double quotes) from a string. Your answer is also correct but he told nothing about quoted strings.

The problem is, we have a question but no explanatory examples. Something like xxxx is the string I have, and
 yyyyy  is the string, I want to get.

To help you, help us to help you. This means, show us what you have you already done. So we can you point in the right direction, maybe explain, why your solution dosn't work, etc. It's nothing bad to ask for help. At some point in the time we all were new to Studio and ObjecScript.

Just asking for a solution is like going home from the school and letting the parents make the homework...

So what have you tryed?

For us all, the common denominator is Cache/IRIS and we have, as you know, Cache/IRIS for Win, Linux, AIX and MAC platforms. It's nice to know about existing external tools, but for some of us the COS solutions remains as the last resort, especially if those (external) tools do not exists for the OS, one works on (Just My2Cents).

First, as you alread wrote, changing the collation of an already existing installation is dengerious,
second, as far as I know, the database creation page (of ManagementPortal) offers you "Cache/IRIS-standard" and "Cache/IRIS-standard string" only. Nevertheless, changing to "standard string" only affects the collation and not the display, i.e. string subscripts will be displayed quoted but numeric subscripts are not quoted.

However, those legacy systems are already in operation, therefore they neither need python nor 3DES, at most, an upgrade to an current system. Hence, I don't understand your argumentation.

Just a hint, 3DES (and DES anyway) are old technologies and shouldn't be used anymore. 

The following links have more (detailed) informations:

https://csrc.nist.gov/news/2017/update-to-current-use-and-deprecation-of...
https://www.cryptomathic.com/news-events/blog/3des-is-officially-being-r...

justmy2cents