Here's a quick example. In short:

  • View Other
  • Click in the document
  • Click the thing that shows up in the bottom status bar
  • Enter routine + offset (e.g., copy/paste from error message) and hit enter.

It would be nice if this was available via quick pick based on the isfs context (including the routine, not just the tag+offset).

@Dmitry Maslennikov it's not actually a REST service, I just want a web application where I have full control over behavior of URLs under the application root in ObjectScript. %CSP.REST is the easiest (maybe only?) way to do that.

I ended up implementing Login as follows (which at least mostly works):

/// Called for a REST page in the event of a login being required
ClassMethod Login(skipheader As %Boolean = 1) As %Status [ ProcedureBlock = 0 ]
    // Support including logo image (most of the time...)
    Set brokerApp = "/csp/broker/"
    Set brokerName = $Replace(%request.URL,$Piece(%request.URL,"/portal",1),brokerApp)
    If (brokerName '= brokerApp) {
        Set filename = $System.CSP.GetFileName(brokerName)
        If ##class(%Library.File).Exists(filename) {
            Set %response.ServerSideRedirect = brokerName
            Quit $$$OK

    // Redirect with trailing slash (supports above)
    If ($Extract(%request.CgiEnvs("REQUEST_URI"),*) '= "/") && (%request.URL = %request.Application) {
        Set %response.Redirect = %request.Application
        Do %response.WriteHTTPHeader()
        Quit $$$OK

    // Suppress "Access Denied" error message
    If %request.Method = "GET" {
        Set %request.Data("Error:ErrorCode",1) = $$$ERROR($$$RequireAuthentication)

    Quit ##class(%CSP.Login).Page()

Not sure if this is what you're getting at, but one of the most exciting and unique things about ObjectScript is how natural it is to do metaprogramming (in the sense of writing ObjectScript that treats other ObjectScript code as data). Because all of your code is in the database, you can work with it from an object or relational perspective - see the %Dictionary package.

There are to main ways of doing this: generators and projections. A generator produces the actual code that will run for a method or trigger in a class at compile time, typically based on the class definition. A projection adds side effects of compiling/recompiling/deleting the class (e.g., updating a global with metadata about the class, creating + queueing compilation of other classes). has a lots of examples of both of these; here's a representative sample: does a bunch of SQL/object updates to data after compilation (which uses that projection) has a CodeMode = objectgenerator method that fails compilation of subclasses if certain methods are not overridden. creates a separate class with dependencies on other classes properly declared and queues it to be compiled. The class created extends which defines some methods with CodeMode = objectgenerator, though a separate class does the actual work of code generation.

@Ron Sweeney this seems like a good use case to define your own package with dependencies for the things you want to "install if not already installed" - installing your package will install those dependencies only if they haven't been installed. (And if the versions update, they'll be updated.)

Alternatively, you could do something like:

if '##class(%ZPM.PackageManager.Developer.Module).NameExists(packagename) { zpm "install "_packagename }

... ended up answering my own question in less time than it took to write it up. Solution (which might just be a workaround) is to force the content-type on the response to be application/octet-stream:

do"ContentDisposition","attachment; filename=""""FileName")_"""")
set %response.Redirect = "%25CSP.StreamServer.cls?STREAMOID="_..Encrypt(

@Eduard Lebedyuk it depends on the caller. In a CI process I could imagine doing different error handling for failed compilation vs. failed unit tests, this would be a way to signal those different modes of failure.

I've taken/seen approaches that are more shell-centric vs. more ObjectScript-centric which would be a driver for this being useful. With the package manager it's generally simpler to wrap things in <Invoke> or resource processors and then call IRIS with individual zpm commands (i.e., load then test) from CI. For some of my pre-package manager CI work we've had a big ObjectScript class that wraps all the build logic, running different sorts of tests, etc. In this case it would be useful to indicate the stage at which the failure occurred.

Regardless, $System.Process.Terminate is simpler to manage than "flag files" for sure, which would be the next best alternative. (IIRC in old days, maybe just pre-IRIS, there were Windows/Linux differences in $System.Process.Terminate's behavior, and that led us to use flag files.)

On further investigation, it seems that what I need just isn't in the old version I'm running.