Did you intentionally start your Serenji service process on port 43221 rather than the default port, which is 43211?
You can check the status of that service process by running this command in a Cache Terminal:
D ^%Serenji
The output includes a section like this:
Serenji explore/edit/debug service ---------------------------------- Service status: Running Primary port: xxx Aux port min: xxx Aux port max: xxx Server address: xxx
Nice to see this preview appear, and being a Docker container made it easy for me to download, spin up and verify that our Serenji extension for VSCode seems to work fine. Not that I'm surprised, seeing how good at maintaining backward compatibility I've always found ISC to be.
Version 3.0.3 has just been published. Main new feature is support for web app files (CSP, CSR and other text types). These appear in the tree under the package associated with the app:
Other changes:
My guess is this is on Windows, and the Windows service that HealthShare runs as is configured to Log On As a specific Windows account. Check those credentials. Perhaps the password has been changed, or the account has expired, or been disabled. Look in the Windows event logs (probably the Application one). Another source of info is the cconsole.log file in the mgr subfolder of wherever you installed HealthShare.
Your problem doesn't seem likely to be specifically related to Cache Studio.
@Douglas.Fosterif you're going to get the HALT info added to the Docker Hub page, maybe also clean up the debris I've highlighted below:
Be aware that if you're using InterSystems IRIS Community Edition you can't do this.
If you agree with me that InterSystems decision to disable the mapping features in Community Edition should be reversed, please go to https://github.com/intersystems-community/iris-community-edition/issues… and +1 this issue.
We just published 3.0.2. If you already installed 3.0.0 your VSCode extension should upgrade automatically next time VSCode checks for extension updates. Or you can trigger that from the "..." menu on the Extensions viewlet. For best effect you should also upgrade the server-side part wherever you've previously been connecting from 3.0.0.
Changes in 3.0.2:
Serenji is also listed on Open Exchange.
We have no current plans for implementing Serenji for VS. The architecture of VS is significantly different from that of VSCode.
I notice that your mappings get code from ENSLIB
My use-case is a bit different.
Can you create a new database and namespace pair called XYZ and then define a %ALL mapping so that the globals ^XYZ and the routines XYZ* and the package XYZ get fetched from your XYZ namespace from all other namespaces, e.g. USER ?
I'd expect mappings to ENSLIB to work, otherwise the "Ensemble" features of IRIS would be broken in Community Edition.
It seems to me that those are allowed but mappings we define to our own databases get ignored.
I was able to create the mappings, but they don't seem to work for me. Not even after an IRIS restart.
I'm using the %ALL pseudo-namespace.
There's a section about Community Edition limitations in the document at https://irisdocs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Pag…
Here's a screenshot of what it currently says:
A big disappointment for me is the exclusion of namespace mapping. Those of us who create tools for the InterSystems world commonly use namespace mapping to make our tools available in the users' namespaces. See Evgeny's article here
Expanding on what Evgeny wrote, the new Serenji extension from us at George James Software gives you an experience that's most similar to what you're used to with InterSystems Studio. It connects you directly to the namespaces of your servers, even if they're running versions that are too old to support the Atelier REST APIs which other VSCode extensions depend on.
Plus, Serenji offers debugging.
A new license is needed. We offer an upgrade price. See https://www.georgejames.com/snjPriceUSD
To clarify Robert's answer, on InterSystems IRIS the database is called IRISLIB, and on Caché, Ensemble etc it is called CACHELIB.
But rather than having to reload your own non-%Z/%z routines after every upgrade you could create a dedicated database for those routines and then use %ALL-type mapping to make the routines available in all of your namespaces.
More info:
Given that this is Windows, the behaviour can differ depending on whether you're connected to Cache using telnet or are running a Terminal session on the desktop of the cache host.
Some related articles:
@oliver russell I think you are confusing the name of an InterSystems product (Caché) with the term 'cache'. Easy mistake to make, ever since InterSystems released Caché a couple of decades ago.
In a Terminal you can issue a ZNSPACE command or run DO ^%CD and swap to a database (technically, an implied namespace). See the ZNSPACE doc here.
Or if you want to do your exporting from the System Explorer section of Portal, use the dropdown on the left-hand panel to change from a "Namespaces" perspective to a "Databases" one.
It's normal that you don't have INT code for library classes such as %Stream.FileBinary. When InterSystems builds the CACHELIB database that contains these classes they don't set the "k" compile-flag.
Take a look at methods in the %SYSTEM.Encryption class.
Like many of the classes in the %SYSTEM package, you can easily access its methods via $SYSTEM, e.g.
USER>d $system.Encryption.Help()
'Do $system.Encryption.Help(method)' will display a full description of an individual method.
Methods of the class: %SYSTEM.Encryption
AESCBCDecrypt(ciphertext,key,IV)
This method performs AES decryption in Cipher Block Chained (CBC) mode.
...
Right. And this is the reason why the tool with XYZ.Classes should be installed in XYZ namespace - in this way even if I map XYZ to %All all the data persistent data for XYZ.Classes will be stored in XYZ namespace, even if I use it from USER namespace, right?
This is only true if you explicitly add a global mapping of ^XYZ.* to the XYZ database (NB, mappings point to databases, not to namespaces). If you only mapped the XYZ package to XYZ, when an instance of persistent class of that package is saved from within the USER namespaces its data will get stored in the USER database.
Why do you think we need a prefix for globals? The matter to have a dedicated namespace/database for the tool frees us from this requirement, right?
If tool XYZ is installed in namespace+database XYZ and consists of classes in the XYZ package that's %ALL-mapped from XYZ, default storage for persistent classes in that package will use globals ^XYZ.* which will get stored in the default data database of whichever namespace the tool is used in (e.g. USER). These globals mustn't clash with globals created in the same place by a tool from a different supplier, or by the end-user's own apps.
If tool XYZ opts to consolidate user's data into the XYZ database, the natural way of doing this is with package mapping, in which case it's still necessary to avoid name collisions. There are ways the XYZ tool could use extended global references to route data into its private database, but this adds complexity.
Some initial thoughts:
- There should be a central name registry, to avoid clashing on namespace/database names, package names etc between different package providers.
- Consider assigning a top-level reserved package name (also prefix for globals and routines), and a namespace/database prefix, to avoid clashes with names that end-users of the tools might pick.
- What's the upper limit on namespaces? Databases? Any relevant constraints for Community Edition of IRIS?
- Adding a namespace for each tool package will lengthen namespace lists in Studio, Portal etc. Maybe tools don't always need a namespace in front of their database. Ones that present a web app / REST interface probably do (at the moment) because of how the app config has to point to a namespace.
- Tools should be able to register stuff that needs to be run during environment startup and shutdown. The current need to create/edit %ZSTART / %ZSTOP routines is clunky.
What platform are you running Cache on? And what Cache version? Can't you access the Windows fileshares directly from ObjectScript without needing to call out through the Java gateway?
What $ZVERSION are you running?
Perhaps there's a faulty cached query.
The 2012.1 docs here describe how to use Portal to see what's in the cache, and how to purge items from it.
The IRIS-based products don't ship a SAMPLES database. Instead there's a documented procedure for setting up your own, then fetching the samples you want.
In that case I'd like to lobby for devchange JGM785 to get into Ensemble 2018.1.2. This devchange addresses a longstanding weakness in Portal, namely that its schema editor didn't respect server-side source control.
Is there an ETA for 2019.1 preview versions of Caché and Ensemble, for those who haven't yet migrated to InterSystems IRIS?