InterSystems changed how <MAXNUMBER> was signaled during conversion from text representation to numeric representation when support for 64-bit IEEE binary floating point was added to Caché.  Textual numbers that overflowed the default ObjectScript decimal representation were now converted to 64-bit IEEE binary floating point which supports a much larger range of magnitudes.  When a literal would exceed the magnitude of IEEE floating point, the choice of whether to signal <MAXNUMBER> depends on the run-time $SYSTEM.Process.IEEEError setting since IEEE floating-point overflow can either signal <MAXNUMBER> or it can return an IEEE floating-point infinity.

The quoting of the slash character, "/", is optional in JSON.  When doing a $ZCVT output conversion ,"O", in JSON IRIS chooses to not quote the slash character.  It makes the output easier to read.  However, $ZCVT doing an input conversion, "I", will recognize a quoted slash character in JSON input.  E.g.:

USER>w $zcvt("abc\/def","I","JSON")
abc/def
USER>w $zcvt("abc/def","I","JSON") 
abc/def
 

A future release of IRIS will restore the ability of %DynamicArray and %DynamicObject classes to dispatch method calls on the method names of the form "propertyGet" and "propertySet".  However,  $PROPERTY(dynobj,"Id") should be more efficient than $METHOD(dynobj,"IdGet") so we recommend using $PROPERTY over using $METHOD when working with %DynamicObject class objects.  When the property name is known before execution time then dynobj.Id is the best way to do a simple property access of a %DynamicObject element with key name "Id".

A change was made to how IRIS dispatched method calls because there existed a few unusual cases where there was no property named "property" but the programmer was trying to dynamically dispatch to a method with the name "propertyGet" and the result was an undefined property error rather than a method call.  The change was made so that a method named "propertyGet" could always be correctly called when there was no property named "property".

Every possible string is a legal %DynamicObject key name and if the key name element is not otherwise defined then that key name element contains the empty string value.  The implementation of the %DynamicObject class does not include a list of all legal property names since all key name strings are legal.  The new way of dynamically dispatching method calls with names like "propertyGet" would first check if the property named "property" existed before attempting a property dispatch instead of method dispatch.  Since a %DynamicObject class object did not contain the name "property" in the list of legal property names and did not contain a method called "propertyGet" in the list of legal method names, the result of evaluating $METHOD(dynobj,"propertyGet") was a <METHOD DOES NOT EXIST> signal.  The future release of IRIS will have $METHOD(dynobj,"propertyGet") dispatch a property access rather than attempting a dynamic dispatch of a method access.

I should point out that "%" is a legal key name string but $METHOD(dynobj,"%Get) did not fetch (and will not fetch) the element with key name "%" because a %DynamicObject does contain a method named "%Get".  A call on a defined method name always occurs before attempting a dynamic method dispatch.

See the documentation on the

methods which can be used with subclasses of the %RegisteredObject class.

Another translation is

 Read *R:20
 ;; Test error case

 If '$Test { Use Write !!!,"Expired time." Quit }
 ;; Test character "a" case

 If $c(R)="a" {
   Use Write !!!,"A letter a has been read."
   Quit
 }
 ;; I added more code here to demonstrate "fall through" in original
 ;; when neither timeout nor "a" occurs
 Use 0
 Write !,"A character other than ""a"" was read"
 Quit

 ;; Since all 3 cases execute Use 0, this statement can be placed after Read and the other 3 copies deleted
 

It might be easier just to always make your BREAK commands conditional like (Robert Cemper suggests above).  Do it like:

    BREAK:$GET(^|"USER"|MyNameBreakAppEnable)

Use your own name for "MyName".

Then you do SET ^|"USER"|MyNameBreakAppEnable=1 to enable break points and
KILL ^|"USER"|MyNameBreakAppEnable to turn break points off.

Change the name of "App" to conditionalize break points for use in different applications.  And "USER" is a scratch namespace available on all the instances you plan to do debugging on.

The ObjectScript command
   ZBREAK %method^%CSP.Broker.1
or
   ZBREAK zmethod^%CSP.Broker.1
will allow you to set an ObjectScript debugging breakpoint at the entry of "%method" or "method" of that class.  The ObjectScript commands  BREAK "S" or BREAK "S+" would then allow you to single step through the statements in that method.  See documentation on ObjectScript debugging for more details.

Unfortunately, the ObjectScript routine %CSP.Broker.1 on my IRIS instance is "deployed" which means the %CSP.Broker.1.int routine source code is not available and I assume the %CSP.Broker.cls source code is also not available.  Without one of these source files you will be debugging and single stepping blind through the ObjectScript commands.  Some of InterSystems classes and routines are not "deployed" which means you can do Command-line Routine Debugging.  You can also modify those classes/routines after you change the IRISLIB database from readonly to read-write.

It is best that you take the advice above to contact support in the InterSystems WRC.

I am assuming your problem is that request.HttpResponse.Data.Read() is complaining because you are reading the entire pdf file into an ObjectScript variable with its maximum supported string length of 3,641,144 characters.  You will have to read it out in smaller chunks that individually fit into an ObjectScript string.  The chunksize will be important as you pass the chunked data to $system.Encryption.Base64Encode(content) and your chunks cannot end between the boundaries between two different BASE64 encoding blocks.  The results of each Base64Encode must then be sent to some form of %Stream (probably %Stream.GlobalBinary or %Stream.FileBinary) since only a %Stream can hold a block of data larger than 3,641,144 characters.  Using a small, appropriate chuncksize will limit the in-memory resources used by this conversion.

If you don't mind having the entire PDF file in memory at one time you can use %DynamicObject to hold and decode that base64 data.  The %Library.DynamicObject and %Library.DynamicArray class objects are usually used to represent data that was originally JSON encoded.  These Dynamic Objects exist only in memory but you can serialize them into JSON textual representation using the %ToJSON(output) method.  But if the JSON text representation contains more than 3,641,144 characters then you better direct 'output' into some form of %Stream.

You can convert a binary pdf file into BASE64 encoding doing something like:

SET DynObj={}  ;; Creates an empty %DynamicObject
DO Dynobj.%Set("pdffile",request.HtttpResponse.Data,"stream")
SET Base64pdf=Dynobj.%Get("pdffile",,"stream>base64")

Then Base64pdf will a readonly, in-memory %Stream.DynamicBinary object which is encoded in BASE64.  You can use Base64pdf.Read(chunksize) to read the BASE64 out of Base64pdf in ObjectScript supported chunks.  You do not have to worry about making sure the chunksize is a multiple of 3 or a multiple of 4 or a multiple of 72.  You can also copy the data in Base64pdf into a writeable %Stream.FileBinary or a %Stream.GlobalBinary using the OtherStream.CopyFrom(Base64pdf) method call.

If your HttpResponse contains a BASE64 encoded pdf file instead of a binary pdf file then you can do the reverse decoding by:

SET DynObj={}
DO Dynobj.%Set("pdffile",request.HtttpResponse.Data,"stream<base64")
SET BinaryPDF=Dynobj.%Get("pdffile",,"stream")

Then BinaryPDF is a readonly %Stream.DynamicBinary containing the decoded pdf data.  You can copy it to a %Stream.FileBinary object which can then be examined using a pdf reader application.

The %ToJSON method sends JSON text to a device or %Stream one element at a time.  Starting in IRIS 2019.1.0 it broke up long JSON strings into blocks of 5460 characters so that strings exceeding the maximum length could be sent to the device.  Make sure you are using an IRIS 2019.1.0 or later if you are getting a <MAXSTRING> signal.

In a future IRIS release (now out in a preview release) a change was made such that sequences of many small items would be blocked together and sent to the device in a larger buffer.  This is being done to improve the performance of %ToJSON method when sending many small elements to a %Stream.

Although InterSystems allowed unlicensed use (with some limitations) of Caché by educational institutions very few colleges/universities took advantage of this.  The exception seemed to be universities in Russia.  When we had contests for the best Caché applications we would offer the university winner a free trip to Global Summit.  However, a recent Russian student was unable to attend because she could not get a Visa to visit the US.

Maybe IRIS with embedded Python could help increase university interest in IRIS databases.