If one of your packages on OEX receives a review, you get notified by OEX only of YOUR own package.
The rating reflects the experience of the reviewer with the status found at the time of review.
It is kind of a snapshot and might have changed meanwhile.
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.
Some were accepted and merged, and some were just ignored.
So if you made a major change and expect a changed review, just let me know.

Over the last 9 years, I published more than 90 packages in OEX.
And over this time, conditions and environments changed.
In the beginning, there was

• no Docker
• no IPM/ZPM
• no embedded Python, no AI
• Caché, Ensemble, CSP, ZEN, .... were dominating

As time changed, also product versions and external languages changed.
Adjustment of a few packages was no issue in the beginning,
and was a matter of support quality to my "consumers".

With the actual volume, I see no way to keep this target up for all my packages.

If one of your packages on OEX receives a review, you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review, just let me know.

If one of your packages on OEX receives a review, you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review, just let me know.

If one of your packages on OEX receives a review, you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review, just let me know.

A previous attempt was assisted by an external Python method.
This is all classic CSP written with ISOS, JavaScript, HTML
Besides the graphic, you also get concrete numbers freshly collected from your local
instance or from remote instances that also installed the package. 

The final result

The processing steps 

• A CSP page is called by its URL
• In method OnPreHTTP
  • The System Query fills the temp table from %SYS
  • If the correct URL parameter is provided 

In my previous article, I structured network communications
in these 3 possible layers, and covered the last

• Client <---> Transport
• Server <---> Transport
• Client <---> Server

In fact, you have the most control over the last one.
The IRIS side as a server is yours and under your full control. 
Up to now, the Transport layer was assumed to be as passive as a bare wire.

This assumption should be verified. I once met a Windows environment with
a quite surprising setup where a Firewall-like filter was isolating internal
processes and causing a lot of trouble.

Chasing errors or misbehavior in the network can be quite a challenge.
Differently to  a local application on the DB server, you always have at least 3 players:

• A client  to place a request 
• some kind of transport layer
• and a server to provide a reply.

This results in a minimum of 3 possible communication layers

• Client <---> Transport
• Server <---> Transport
• Client <---> Server

The last one is probably the easiest  to check, while the other 
two deal with the same counterpart just from opposite sides.

If one of your packages on OEX receives a review, you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review, just let me know.

If one of your packages on OEX receives a review, you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review, just let me know.

using  intersystemsdc/iris-ml-community:latest I failed with

Error: Invalid Community Edition license, may have exceeded core limit.
Shutting down the system : $zu(56,2)= 0Starting IRIS

What is the actual valid version with ML ??

If one of your packages on OEX receives a review, you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review, just let me know.

If you start with InterSystems ObjectScript, you will meet the XECUTE command.
And beginners may ask: Where and Why may I need to use this ?

The official documentation has a rich collection of code snippets. No practical case.
Just recently, I met a use case that I'd like to share with you.

The scenario:

When you build an IRIS container with Docker, then, in most cases,
you run the  initialization script  

iris session iris < iris.script

This means you open a terminal session and feed your input line-by-line from the script.
And that's fine and easy if you call methods, or functions, or commands.

As in the previous package, all is running from a CSP page.
And it is all classic CSP written with InterSystems ObjectScript, JavaScript, HTML
Besides the graphic, you also get concrete numbers freshly collected from your local
instance or from remote instances that also installed the package. 

The final result

The processing steps 

• A CSP page is called by its URL
• In method OnPreHTTP
  • The System Query fills the temp table from %SYS
  • If the correct URL parameter is provided 

To better understand Streams in IRIS I'll start with a short

History

In the beginning (before IRIS), there was just basic access to external devices.
The 4 commands OPEN, CLOSE, READ, WRITE still work and are documented 
by  Introduction to I/O in detail.
Especially for files, this is a direct access to your actual file system.
You have to take care of any status or other signal in your code.  
Also, any code conversion or similar is up to you. 

Class %Library.File aka %File offers a large collection of methods and queries 
for standard operations on directories and files.

If one of your packages on OEX receives a review, you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review, just let me know.

Finishing my previous example for multiple IRIS instances, I tried
to compose a local single instance version.  The step from the external
Python app to a version using embedded Python seemed to be obvious.
This was a wrong assumption, as some Python libraries just refused installation
into my local Windows-based environment.

These are the strategic plans of my example for the External Languages Contest 2025

It's about an example for the External Languages Contest 2025

You get almost any information about your databases in IRIS using 
the System Management Portal. After passing several levels, you often
get a wide list of items, but the interesting ones are hard to find.

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review, just let me know.

The article was motivated by the 2025 September Article Bounty

The principle of Docker is just convincing to me.

• Get a sandbox where you play and try whatever you want/need to do
• Once done. You drop it without leaving traces in your working environment

This was the technical base for me to run about 700 reviews in OEX 
with almost no side effects  (except those caused by myself).

For beginners, I'll start with straight pure IRIS, no *health, *ML, *whatever

First, you need a Docker installation. It's available on almost any platform.

Reviewing my published packages, I identified a nasty bug in IRIS Native API

• There is a method in  %Net.DB.Iris named function ()
• It's equivalent to  ObjectScript $$label^routine(param) 
• It used to work fine 2 years ago, when I published my command-line-extension packages
• Now it is broken since at least 1 year and throws <PROTECT>
• I identified it for ObjecScript, Java, Python, Node.js
• It is reported as WRC# 1002589
• For all 4 cases, I also verified a workaround
  • Instead of calling an ObjectScript Function you call a Classmethod
  • It's by %Net.DB.Iris ClassMethodValue(.

If one of your packages on OEX receives a review you get notified by OEX only of YOUR own package.   
The rating reflects the experience of the reviewer with the status found at the time of review.   
It is kind of a snapshot and might have changed meanwhile.   
Reviews by other members of the community are marked by * in the last column.

I also placed a bunch of Pull Requests on GitHub when I found a problem I could fix.    
Some were accepted and merged, and some were just ignored.     
So if you made a major change and expect a changed review, just let me know.

If you are investigating complex structured Globals this can become
a rather boring typing exercise. Different from Global Explorer in
System Management Portal Global-Inspector allows a kind of drill-down
to dig deeper and deeper by subscript levels.
You also have the option to see the stored content or to show only
the subscript structures.
Globals storing SQL Tables are probably not so thrilling, but in SYSTEM
space you find real trees with completely different branches and twigs.

Global-Inspector can run in browser or from terminal command line.