Hi,

1. Yes, there a few options for debugging ObjectScript code in VSCode, including running any class method or routine, attach to a running process, only CSP debugging not supported, yet

2. VSCode offers a ways to run system’s terminal internally. And you can run IRIS terminal there, if you working locally. If you working remotely, you’ll need to configure remote access to it, with ssh or telnet, and connect to it from VSCode internal terminal. Yes, as an option could be web terminal.

Hi @David Loveluck, and anybody who wanted it.

Have a look at one of my latest projects. I did Grafana plugin for IRIS, which can connect and gather any data directly. It's in active development and will be extended with much more possibilities very soon. And I'm going to publish it on Grafana Plugins list as well, for easier installation. Stay tuned, and do not hesitate to contact me directly or through issues in the repository, if you have some advice, what would you like to see there first.

You can do it by yourself. I would recommend looking at the page of all emoji list in Unicode. There you may find a link to the latest version of data in text files, which will be possible to parse quite easily with ObjectScript. So, you can just import that data and use it as you want. And you will need to update it regularly when it gets some new emojis.

You can check how many license units available with this method $SYSTEM.License.LUAvailable()

And next depends on the kind of application, you develop. If it's some web application, and you have to achieve it for web session, I would try using %CSP.SessionEvents with OnLogin event, check how many license units are available and who is logging in, and decide to decline the login.

If you need it for some else ways of connections, I think the best place would be ZAUTHENTICATE.

Since 2016.2 there are no reasons to keep storing source code in XML. Even in transition process, I would recommend to store codebase based on the lowest supported version of platform.

Cache and IRIS able to export and import source code in UDL format, as seen in VSCode. 
 

If you would stay with XML format just because you’d like to keep history consistent, it can be solved by converting entire history in the like it was always in UDL.