• .MAC  and much more .INT  are an almost 1:1 image of the runtime .OBJ code
• they get implicitely compiled by ZSAVE command
• while any .CLS gets first stored with a lot of internal parameters where XML is faster than UDL
• then it's translated to .INT(at least) including all extra params,  
• and inherited pieces and other features for comfort 
• and then compiled as any other .INT for the final .OBJ 

So comparing .CLS  to .MAC/.INT is like comparing a goat to the final cheese you buy.

A few questions:

• my local IPv4 address in the ODBC connection
  • in ODBC you have to specify the IP address of the Caché server 
  • there you create the connection FROM YOUR local server
  • by default there's no connection outgoing from Caché
  • No need for your local IP - eventually for some firewalls
• enabling remote access 
  • if you have username + PW from Caché you should have access
  • only some firewalls on server or client may block you
• more important: what OS do you run on server and client ?    
• and what type of connection do you try to establish ?  Web, SuperServer, Terminal, ... ?

To get the property position dynamically by program you may use this ClassMethod
 

ClassMethod PropSeq(classname As %String = "", propname As %String = "")
   As %String [ SqlProc ]
{
    if classname="" set classname=..%ClassName(1)
    set pos=0
    &sql(
        SELECT SequenceNumber INTO :pos 
        FROM %Dictionary.CompiledProperty
        WHERE transient=0
        AND parent=:classname
        AND name=:propname
    )
    if SQLCODE set pos="-1;"_SQLCODE
    quit pos
}

a somewhat 'dirty' approach

select ID, Name_GivenName from Demo.DemoPatient 
where FOR SOME %ELEMENT(Demo.DemoPatient.Aliases) ($LISTFIND(%value,'Twain')>0)

advantage - no need to know the structure of your serial class
risk - false positives for unexpected coincidences.  eg. Washington, John, ...

This article is focused on indexing, though it shows the principle of the SQL query
Effective use of Collection Indexing and Querying Collections through SQL
 

it applies to any code in ObjectScript

start here in docs

BIG THANKS!
That soved the problem

It's a shame that the owner of the package didn't react to the ISSUE on Github or OEX for 3 months

run

USER > zn "%SYS"
%SYS > ZLOAD JOURNAL
%SYS > Print

in WebTerminal you just get NOTHING
in normal terminal and iterm  you see the code  

@Mario Sanchez Macias  You missed the point.
The essential functionality is to have a total autonomous partition to work in.
It was never named so, but it is the real Shell for ObjectScript and its predecessors for >50 years !

THX

simple case:
write some lines of ObjectScript in TERMINAL with Functions, ....
NO need to compile it, no INT, no MAC, no traces.
Just DO it:
---
or load some  INT., apply your changes, run it, forget it  
no save, no recompile, ...

WebTerminal is based on Xecute and compiled code
Same in Studio.


 

Overall a nice idea.
the package still needs some polishing to convince

suggestion1:  fix issue to build clean docker
suggestion2:  re-enable Start+Stop message so uses see it was moving
suggestion3:  show which class you check , kind of work log
suggestion4:  also step into sub-packages e.g. not just rcc but also rcc.unittests. codeinspector could be a good start
sugesstion5: allow also MAC, INT, INC code to be checked 

I just can repeat my message from OEX review !

it would be great if the issues in building Docker container would be fixed.
so we can touch it and reduce frustration of evaluators first
Actually it is broken,  Issues pending since some days

• is there anywhere a working example using the template ?
• or a hint of how to apply it ?