One other quick comment:

Note that

WRITE ##class(DC.Test).IsString( )  //  -> 1

The IsString function takes a missing argument and assumes it is a string value.  Using an undefined variable as an argument to $LISTBUILD generates an "undefined" $LIST element and does not generate an <UNDEFINED> signal.

I should mention that the numeric comparisons $A($LB(val),2)<3 and $A($LB(val,2)>3 are not quite legal ObjectScript since the internal specification of $LIST string representation is subject to extension in the future.  In previous Caché and IRIS releases the $LIST code type byte for a string could be 1 or 2.  In the future, $LISTBUILD will support compressing string values and those compressed $LIST string elements will use $LIST code type values greater than 3.

It is legal to use such undocumented $LIST representation techniques when debugging new code on a particular Caché/IRIS release.  However, depending on such internal representations in a production application should be avoided since the internal representations can change in the future.

Example: some programmers have used the string equality operation, ls1=ls2, to test if two $LIST strings contain the same values.  They should have used the $LISTSAME(ls1,ls2) function call.  This use of string equality on $LIST strings has resulted in broken applications in the past when extensions were added to the internal specification of $LIST strings.

The original ANSI M (also known as ANSI MUMPS) standard did not distinguish between a canonical numeric string versus a number.  Many early implementations of this standard used strings of numeric characters as the internal representation of a number and did arithmetic on character strings instead of converting the numeric string to a binary representation and then using the hardware binary arithmetic instructions.  The result of a numeric operation would always be a character string using the canonical numeric representation.

In such an implementation there was no way to tell the difference between the character string "123" and the literal 123 since "123" was the canonical numeric string representation for that value.  For performance reasons, InterSystems ObjectScript has several different internal representations it can use for the number 123.  It can use the three character strintg "123"; it can use the 32-bit binary integer 123; it can use one of several representations of 123 in ObjectScripts' decimal floating point representation which has a 64-bit binary integer significand combined with an 8-bit power-of-10 exponent.  Writing 12300E-2 will usually be represented with the decimal floating-point representation and not with the integer repersentation.

The command WRITE $LISTSAME($LISTBUILD("123"),$LISTBUILD(12300E-2)) will write 1 because the string "123" and the numeric literal 12300E-2 are the same value.  However WRITE $LISTBUILD("123")=$LISTBUILD(12300E-2)) will write 0 because the $LISTBUILD will will generate different string encodings in this situation even though the values are considered to be identical.  Although $LISTBUILD could convert different internal representations into identical $LIST strings, it is faster just to place the internal representation into the generated binary string.  This is why you must use $LISTSAME when you want to check if two $LIST strings contain the same value.

There are a very few functions built into ObjectScript that have a behavior that depends on the internal representation of the argument.  All of these function were inherited when InterSystems extended ObjectScript to have a compatible feature with the language implemented by other vendors who produced extended M/MUMPS systems.  The most common function is $ZHEX(x) which turns a hex string to a decimal number and which turns a decimal number into a string.  Thus, WRITE $ZHEX("10") will write number 16 while WRITE $ZHEX(10) will write the string "A".  If you want to convert variable 'x' from an integer to hex then you need to write $ZHEX(+x) to make sure 'x' is using an internal numeric representation.  If you want to convert variable 'x' from hex to an integer then you need to write $ZHEX(x_"") to make sure 'x' is using the string internal representation.

One additional note:  The literal 123.0 will use an internal numeric representation so WRITE "123.0"=123.0 will WRITE 0 since a string equality comparison operator will be done between the literal string "123.0" and the canonical numeric string "123".  However, WRITE +"123.0"=123.0 will WRITE 1 because the unary plus operator converts the first operand to a numeric representation and then the string equality operator converts both numeric operands into their canonical numeric string representations making the string equality operation be the same as "123"="123".

The %Library.DynamicAbstractObject, %Library.DynamicArray and %Library.DynamicObject classes with the %ToJSON and %FromJSON methods first appeared in Caché 2016.2.  I believe that 2016.2 also included JSON constructor syntax in ObjectScript.  I.e., you could write SET jsonvar={"number":1.2, "string":"abcd",null,true} as an executable ObjectScript statement.  Any JSON constant array or object is legal.  I am not sure when JSON constructors involving ObjectScript expressions was allowed.  E.g. SET jsonvar={"number":(1+.2+variable1), "string":("abcd"_variable2),null,false}.  Newer versions of Caché have more JSON support and IRIS has even more support, including the %JSON.Adapter class.  Inheriting the %JSON.Adapter class makes it possible to use the %JSONImport/%JSONExport methods which can read/writeJSON representation into/from ordinary class definitions.

In particular,  an object is garbage collected when there are no ways to access that object using oref values starting from an oref-type value stored in a local variable.  When an oref is converted to an integer (or to a string) then that does not count as an object reference.  Store that integer/string in a PPG and then do KILLs (or otherwise make changes) of oref-type values referring to an object then that object will be deleted despite the fact a PPG (or any other variable) contains an integer/string reference to the object.

Sorry about that.  My browser only showed this part of the URL:   https://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?...  I did not notice ?... which indicated a longer URL than what I was really looking at.  The shorter URL I thought I was looking at gives the Class Reference page of the InterSystems documentation web site.

The SubclassOf query in ##class(%Dictionary.ClassDefinitionQuery) executed by a SQL SELECT command on a particular instance does provide a way to look at the subclasses of a class on that instance.  The query provides an even better way for executing code in program that needs to do a run-time search for information that is machine readable.

The local Class Reference web page supported by a particular Caché instance is probably an easier way to find a human readable display of the subclasses.  After clicking on a SubClasses Summary links then you probably want to again click on other links (especially the nested SubClasses Summary links.)
 

The class reference at docs.intersystems.com will tell you about InterSystems supplied classes but it will not tell you about user written classes that are extended from a system supplied abstract classes nor about a user class extended from other user classes.

Look at the following with your browser:  http://localhost:57772/csp/documatic/%25CSP.Documatic.cls , where localhost is the system name on which you are running Caché and 57772 is the WebServer port of your Caché instance.  (If you were running IRIS your WebServer port would look something like 52773.)

Once you are on the Class Reference web page then navigate to find the particular class in which you are interested.  Look at the SubClasses Summary section to find inherited classes.  You can click on the an inherited class name to navigate to the Class Reference information of that class.

Leon has not made a return comment and his original question would be ambiguous to some people.  I often call the " character, the 'double quote' character while I often call the ' character the 'single quote' character.  Other names I might use for the " character are 'quotation character' or 'ditto mark'.  Other names for the ' character would be 'apostrophe' or 'apostrophe quotation character'.  [[Notice I am using apostrophe quotation characters in this comment.]]  I might describe "" characters as 'doubled quotation characters' or 'doubled double quotes'.

Since Leon asked to 'remove double quotes (") from a string' my first impression would be to remove all " characters from the string.  I.e., every $C(32) should be removed.  If Leon wanted to only remove 'doubled quotation characters' then he probably would have written 'remove double quotes ("") from a string'.

If your long strings are coming from JSON representation then

   Set DynObj=##class(%DynamicObject).%FromJSON(...)

will create a  %Library.DynamicObject or %Library.DynamicArray object in memory containing the JSON array/object elements where the sizes are limited only by the amount of virtual memory the platform will allocate to your process.  A string element of an object/array can have many gigabytes of characters (virtual memory permitting) and you can get the value of such a huge string element in the form of an in-memory, read-only %Stream doing:

   Set StreamVal=DynObj.%Get(key,,"stream")

in cases where DynObj.%Get(key) would get a <MAXSTRING>.

The StreamVal (class %Stream.DynamicBinary or %Stream.DynamicCharacter) is a read-only, random-access %Stream and it shares the same buffer space as the 'key' element of the DynObj (class %Library.DynamicObject) so the in-memory %Stream does not need additional virtual memory.

You can then create a persistent object from a class in the %Steam package (%Stream.GlobalBinary, %Stream.GlobalCharacter, %Stream.FileBinary, %Stream.FileCharacter, or some other appropriate class.)  You can then use the CopyFrom method to populate the persistent %Stream from the  read-only, in-memory %Stream.DynamicBinary/Character.

Consider the following:

USER>set num1=1,str1="""1""",num2=2,str2="""2""",num10=10,str10="""10""",abc="abc"

USER>set (x(num1),x(str1),x(num2),x(str2),x(num10),x(str10),x(abc))=""            

USER>set i="" do { set i=$order(x(i))  q:i=""   write i,! } while 1               
1
2
10
"1"
"10"
"2"
abc

The WRITE command treats its expression arguments as ObjectScript string expressions so any argument expression with a numeric value is converted to a string value containing characters.  Note that variables str1 and str2 are strings containing 3 characters starting with one double-quote character, ".  The str1 and str2 values sort among other strings where the first character is a double-quote character.  When you print these subscript strings, the subscripts from variables num1 and num2 print as one character strings,  the subscript from variable num10 prints as a two character string, the subscripts from variables sub1, sub2 and abc print as three character strings and the subscript from variable str10 prints as a 4 character string.

If you use ZWRITE instead of WRITE then ZWRITE will add extra quote marks, will add $C(int) expression syntax and will add other things so that the textual representation that is printed does not contain any unprintable characters and you can see trailing white space.

I wasn't advocating changing a system collation or changing a namespace collation.  I only recommended using ##class(%Library.GlobalEdit) to change the subscript collation of a newly created individual global variable, leaving all other globals unchanged.

You can see the collations loaded into an instance by executing 'DO  ^|"%SYS"|COLLATE' .  I believe in this case the user wants to use built-in collation 133, which should be the version of collation 5 that sorts only strings and does not sort numbers.  It looks like 133 is now considered to be a "legacy collation" as I have problems finding it in the on-line documentation.

You might consider looking at the ##class(%GlobalEdit).Create(...) method.  It has a 'Collation' argument which allows you to change the collation from the namespace default.  Just choose a collation that does *NOT* sort canonical numeric strings in front of non-numeric strings.

I don't recommend ever changing the default collation of a namespace as many utility routines depend on canonical numeric strings sorting in numeric order and not sorting in string order.  Those utilities may not work in such a namespace.

The %GlobalCharacterStream class is deprecated (although I believe it will continue working.)  You should consider replacing it with the %Stream.GlobalCharacter class.
 

The %GlobalBinaryStream class is deprecated and newly written code should instead use %Stream.GlobalBinary.  Of course, existing code that is not needing modification can continue using %Library.GlobalBinaryStream.
.  

“AlertText” is not the name of a JSON object field but is instead the value of a JSON array element.  Assuming you have done your %FromJSON into variable ‘data’ then data.%Get(“params”).%Get(0) will evaluate to the string value “AlertText”.

The %DynamicAbstractObject classes first appeared in version 2016.2 so JSON support in software versions 2017.x will not have many of the more recent new features.  If possible, you really should upgrade to more recent InterSystems versions so you can use more modern functionality.