The general syntax for calling routines from another namespace is:

do label^|namesapce|routine

where

- you can omit the label and

- namespace is either the name of the namespace (like set namesapce="USER") or the path to the database (preceded by two carets), where the routine resides.

I see right now, Config.MapGlobals accesses the ^SYS global via the path to the database (take a look at the Storage section) - so in theory, you  can  call all classmethods from the above class as:

do zClassmethodname^|"%SYS"|Config.MapGlobals.1(args...)

merely, I do NOT recommend to do this (the cass is in deployed mode, so we do not know, what the code really does and (instance)methods are private, so you can't call them from outside).

First, the correct (or better) way for the above code snipet were:

new $NAMESPACE
zn "%SYS"
do ##class(Config.MapGlobals).Delete(...)
quit

second, one can call routines (and (class)methodes are compiled to rotines) from another namespace by using extended syntax, but in that case such a routine uses the globals (if the routine does a global access) from the CALLING namespace. In Your case this won't work because the Config.MapGlobals uses globals which resides in %SYS namespace and not in the namesspace you are in.

Sure, you can check some key points:
- the size of your PDF-file (in bytes) must be the same as the size of the context.strDocument
- the size of the encoded stream must be 1.33 times of the unencoded stream (see below)
- the second parameter of the Base64Encode() method must be set to 1, else you get a stream with line breaks!

set docSize = context.strDocument.Size
set encSize = context.strDocumentEncoded.Size

if -docSize#3+docSize*4/3-encSize { write "Base64 stream has wrong size" }

Your "old" version sent a string, the new version should send a stream - is there everything OK? Just double check all the recent changes.

If you have a (whatever) class with an property like:

Property propName As %Stream.GlobalCharacter;

and you have an instance of that object in a variable obj then a command like the below

write obj.propName --> nn@%Stream.GlobalCharacter

shows you the object reference, which is (formal) an integer number followed by an '@' symbol followed by the name of the class. With other words, what you see is correct.

you miss the object reference!

set context.strDocumentEncoded = B64EncodeStream(request.streamPDF)
// ---------------------------^^^^^^^ this should be something
set context.strDocumentEncoded = ##(your.class).B64EncodeStream(request.streamPDF)

but you have another problems too: your context.strDocument and  context.strDocumentEncoded are currently STRING properties (according to the operation you try to do), which are limitet to a maxlength of 3.47MB!

You have to change both to a STREAM, so you can handle PDFs  larger then ca. 2.6MB (because 2.6 * 4 / 3 ==> 3.46MB, the limit for a string variable).

After you change context.strDocument and context.strDocumentEncoded to a stream properties, you could use this code:

Class DC.Someclass Extends %RegisteredObject
{

Parameter CHUNKSIZE = 2097144;

ClassMethod ToBase64(src As %Stream.Object, dst As %Stream.Object) As %Status
{
	i ..#CHUNKSIZE#3=0, src.Rewind(), dst.Rewind() {
		set sts=$$$OK
		while 'src.AtEnd,sts {
			do dst.Write($system.Encryption.Base64Encode(src.Read(..#CHUNKSIZE,.sts),1))
		}
	} else { set sts=$$Error^%apiOBJ(5001,"Chunksize or src/dst-problem") }
	
	quit sts
}

}
if ##class(your.class).ToBase64(context.strDocument,context.strDocumentEncoded) write "OK"

It seems, this task will take some time... you have to check, how context.strDocument is populated and  how context.strDocumentEncoded is later in code used. Good luck.

it looks like an OREF but it is just a string, try

set obj = [1,2]
write obj --> NN@%Library.DynamicArray
write $isobject(obj) --> 1
set ^myGlobal = obj
set obj=^myGlobal
write obj --> NN@%Library.DynamicArray
write $isobject(obj) --> 0

see also my answer in https://community.intersystems.com/post/handling-globalcharacterstream-production-service?page=1#comment-189746

It seems, you read the whole PDF into one string thenconverting this to Base64... So there are two "chances to get an error":

- the PDF is longer then the MAXSTRING value (which is 3641144 chars) and

- converting a string to Base64 increases the length of the string by a factor of 1.333 (you get your maxstr here).

The solution is: you read your PDF in chunks, convert this chunks into Base64 and output the converted data into a stream. Due to the nature of Base64, the length of the chunks you read in MUST BE a multiple of 3 (3 input bytes will be converted into 4 output bytes).

As an ObjectScript routine, remove the "ClassMethod" keyword (which, as the name indicates, belongs to classes. Then either  add a "Public" keyword or you remove the brackets ("{", "}") too, but then all variables will have the same scope:

ProcData(file = "c:\temp\zipcitystate.csv") Public
{
    set str=##class(%Stream.FileCharacter).%New()
    do str.LinkToFile(file)
    while 'str.AtEnd {
        set $listbuild(ZIP,CITY,STATE)=$listfromstring(str.ReadLine())
        
        // now you have the individual columns
        // in ZIP, CITY and STATE variables for further processing
        write "Zip=",ZIP,?12,"City=",CITY,?40,"State=",STATE,!
    }
    
    // depending on the way of your implementation, a "kill str"
    // would be needed to free up the file
    kill str
}

Oh, and to invoke the above procedure just do a:

do ProcData^YourRoutineName()
// or
do ProcData^YourRoutineName("path-to-file")

A simple method like


ClassMethod ProcData(file = "c:\temp\zipcitystate.csv")
{
    set str=##class(%Stream.FileCharacter).%New()
    do str.LinkToFile(file)
    while 'str.AtEnd {
        set $listbuild(ZIP,CITY,STATE)=$listfromstring(str.ReadLine())
        
        // now you have the individual columns
        // in ZIP, CITY and STATE variables for further processing
        write "Zip=",ZIP,?12,"City=",CITY,?40,"State=",STATE,!
    }
    
    // depending on the way of your implementation, a "kill str"
    // would be needed to free up the file
    kill str
}

to do the job. Then call the method as

do ##class(your.class).ProcData()
// or
do ##class(your.class).ProcData("path-to-the-file")

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.

To get all the jobGUIDs you need two loops:

f i=1:1:list1.Size f j=1:1:list1.GetAt(i).sensors.Size w list1.GetAt(i).sensors.GetAt(j).jobGUID,!
0b955ee7-9a54-4b13-9af1-7019721faeab
8f9e85ab-31e7-4835-8969-6d72d142a2f1
68cea9d3-54cd-43f2-ae37-aaf47ed43e6b
7602764e-8951-451f-9653-ceb84834a1a6
88d2e472-a1e4-40b3-a108-f2d32a2023e5
116f2ac6-da5f-46da-a7c7-92d9eaf98c89
a878e527-f519-4aaa-bf5d-0d65f72de119
be570b14-0555-4b86-ab9f-e37c40c79216
3a13e243-d6ed-4788-98b2-52e9213bee00
54969869-c4f6-43f6-a74a-2a67f9a73fc5
700af7d3-77b3-4a84-ba11-ea49602d6558
18dc3370-c291-468b-af1f-0361d95bb02c
35d0d2e7-1199-4c18-8941-4fff6dbdba1f
8044560c-94d2-4da7-87f5-07328d9e62c1
b636a2f5-d35f-4c82-9646-e09572336e23
9c9a4bf4-e8af-4b8d-9de2-a99cdff150ed
a576d235-6eb6-4312-a1ff-7b1f767b88ce
654cf21e-daad-4a11-b676-86a7bc8a3360
2be4efc8-6616-4bff-87ba-30fe388a1b34
a5374d6c-311c-44d0-8d06-3a31f33dd3a8
955529c5-36be-4f3e-b768-0e3b377804a7
60a7cdb0-499e-4d02-b4d3-06ee58e40481
e84eda78-1491-49af-9e34-d647e817a251
9bcd5fe6-6f05-4482-ad78-612f35c60b41

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.