If you want to treat them as lists, you probably want to use $LISTFROMSTRING along with $LISTGET, $LISTFIND, and $LISTLENGTH. All of which can be abbreviated to their initials, by the way - $LFS, $LG, $LF, $LL.

set y = $LFS("Red,Green,Orange,Yellow")
set x = $LFS("Purple,Black,Yellow,Pink")
for i=1:1:$LL(x){
    if $LF(y,$LG(x,i)) > 0 { 
        write $LG(x,i)_" found in both lists!",!
        //Or whatever else you want to do when you find a match here . . .
    }
}

Yes, you do have to tread lightly and program very carefully if you mess with those. Errors in them could make it impossible to start or log into IRIS. This is straight from the documentation about those routines:

Make sure that the routines are well-behaved under all possible conditions. They should be written defensively. That is, they should check to make sure that all the resources needed to complete their task are at hand and, if possible, reserved to them before computation starts. Errors which occur are reported as failures of that system function so it is important to think about the design from the viewpoint of error containment and handling. Failure to properly account for recovery in the face of missing resources or the presence of errors has varied consequences: InterSystems IRIS may fail to start; major functions such as Studio may act strangely; or more subtle and insidious consequences may occur which are not immediately detected. It is strongly recommended that these routines be carefully written and debugged under simulated conditions, and then tested under simulated environment conditions before being put into production systems.

It doesn't sound like you're trying to do anything too crazy, but do make sure you trap or catch any potential errors anyway.

When using $EXTRACT, you use a * to signify an offset from the end of a string. So if you did $EXTRACT(Str,1,*-1) you would have the string with the last character removed.

Also note that the arguments for the $EXTRACT are the string, the starting character, and the ending character, so in the examples you gave, you're actually telling it to extract from Str starting at Length(Str)-1. You need to have a 1 in there as the second argument to go from the beginning to that character.

You can also use the $ROLES special variable to do that. It contains both the user's assigned roles and any roles you've added during the process. You can't change the user roles, but if you set it that will add a role. So you could do:

set $ROLES = "%All"

Or whatever role you need to add, then do the stuff that requires that roles, then do:

set $ROLES = ""

That will take away the %All role you added, reverting the process to just the user's normal roles.

Phil, I'm not sure about VS Code, but you can do this in studio by creating a new CSP page with the following contents:

<csp:StudioSimpleTemplate name="CustomCommentHead" type="CLS" mode="new">
/// Organization:
/// Version 1.0
/// Author/Co-author:
/// Project: 
/// Date: 
/// Description: 
/// Change Log:
/// Notes:

Then save and compile that file. It doesn't matter where. Then when you click File, New, Custom, you'll see your CustomCommentHead template. If you choose it, you'll get a .cls file with those lines already inserted.

If you're developing in Studio, open the file that contains that TestAccountSearchWithoutAccount method, then click the "View Other Code" button so you're looking at the INT code. If it says no other code to view, that's fine; you're already where you need to be. There should be a small text field near the top of the window with a drop down arrow on its left end. In that text field, type TestAccountSearchWithoutAccount+6 and press enter. That should take you directly to the line where the error is occurring.

Something on that line is trying to reference an object that doesn't exist. That's what "INVALID OREF" means. Whatever objects are on that line, check how they were created and/or opened and see if there's a chance that the object doesn't exist.

After using your %ExecDirect() method, you should have a %SQL.StatementResult Object. Let's assume you called this object rs (for result set). So you did something like set rs = ##class(%SQL.Statement).%ExecDirect(blahblahblah). From there:

//Get the list of columns
set cols = rs.%GetMetaData().columns
//Loop through the result object
while rs.%Next(){
//Loop through the columns
     for x=1:1:rs.%ResultColumnCount{
     //Get the value of each column
         set colValue = rs.%GetData(x)
         //Get the name of each column
         set colName = cols.GetAt(x).colName
         //TODO: Add whatever you're doing with the name and value here
     }
}

This might be easier to do with XPath rather than a loop.

First, you'll need to create a %XML.XPATH.Document object, maybe using the create from string method:

set sc = ##class(%XML.XPATH.Document).CreateFromString(xmlstring,.mydoc)

Check that the status you get back from that is not an error. If it isn't, you mydoc should be an XPath document. Then you should be able to use the EvaluateExpression method of that document to get what you want, something like:

set sc = mydoc.EvaluateExpression("/Msg/Parties/Party[AgentId=1]/OrgCode","",.value)

If that status is okay, the value you're looking for will be in value, unless there are multiple XML nodes that match that path. W3 provides the XPath syntax specification here.

I've had to do this a time or two in a development environment. Sometimes you can find it under System Operation > Processes and terminate the process. If that doesn't work, you can look at the process ID of the process and kill it at the OS level (the kill command in Linux, or taskkill in Windows). Just be aware that depending on what it's doing and how the task was written, you may end up with some weird stuff.

You could create a new class that extends %ZEN.Component.toolbar, and override the ongetdata property to be a certain method name, then define that method in the class. Then you'd have your own custom tag to use in your zen pages. Here's more information on creating custom Zen components.

Inevitably, though, someone is going to come in here and tell you not to use Zen in any new development because it's deprecated, FYI. Which makes me sad, because I still really like working with it.

In the management portal, go to System Administration, Security, Applications, Web Applications and find your application. Under security settings, disable Unauthenticated, and enable Password.

Then, when you send your requests, you need to include a base 64 encoded basic authentication header with the username and password, or on the end of the URL include ?CacheUserName=username&CachePassword=password. Keep in mind, though, that if you aren't using HTTPS, you could end up transmitting a username and password in plain text or in a very easily decrypted way.

If you want only specific users to be able to access the API, consider creating a new Resource then setting that resource as the Resource Required in the security settings, then only giving that resource to people who need to access the API.