go to post Vic Sun · Nov 1, 2019 Hello Robert, It looks like this message was informing you that you needed to activate a key, and that once you did so the message disappeared. Did you notice any other licensing related messages? What clarification were you looking for in terms of context/content?
go to post Vic Sun · Oct 31, 2019 Hello Yunier, Have you considered mirroring? A reporting async sounds like what you're looking for. Mirroring Reporting Asyncs
go to post Vic Sun · Oct 22, 2019 Pandiyan, OpenVMS is no longer supported for newer InterSystems releases: https://community.intersystems.com/post/vsi-openvms You can also find our supported platform documentation for IRIS 2019.2 here: https://cedocs.intersystems.com/documentation/ISP/ISP-iris20192/ISP_technologies.html#ISP_platforms_patches Other versions' documentation are available at docs.intersystems.com, but no versions of IRIS support OpenVMS.
go to post Vic Sun · Oct 18, 2019 Hello Paul, I believe that log message comes from your own code and I am not sure how your code determined those calls changed. Note that $zu calls are deprecated, undocumented, and subject to change at any time, so you should replace them with supported APIs. Obsolete And Deprecated Functionality I would recommend reaching out to the WRC or your ISC sales rep to discuss further if you have doubts. Perhaps Eduard's post is sufficient for you to replace the functionality. Edit: upon further inspection of the linked documentation, replacements do seem to be available for the calls you mentioned. Config.JournalFreezeOnError Security.SystemDBEncJournal Config.MiscellaneousIEEEError
go to post Vic Sun · Oct 18, 2019 Hello Pandian, This should be a larger discussion with your InterSystems sales rep. I would highly recommend reaching out to them.
go to post Vic Sun · Oct 8, 2019 Hello James, This documentation should contain the answers you seek: Displaying Free Space Information. You can use the System Management Portal's Databases page, or ^%FREECNT. Hope that helps!
go to post Vic Sun · Oct 4, 2019 Hello Rick, You might need to explain more about your criteria. The Business Service should be checking if filename and time modified match to determine if the file is the same. You may be able to just change the timestamp when you want to recheck. Alternatively, you may be able to code some logic to have the files be moved to an archive path and then brought back over into the file path when you want to retry. Settings for the File Inbound Adapter There might be a way to modify the "already processed" status of a file, but I'm not sure if that's a great idea and you may want to discuss it with your InterSystems representative.
go to post Vic Sun · Oct 3, 2019 Hello Sachin, Can you provide the version of your product from the about page in the management portal or "w $zv" from the terminal? This behavior varies across versions so you can probably find more information in the relevant version of our documentation. Also, please be clear about whether you are referring to namespaces or databases. This documentation may be what you are referring to: Where Ensemble Stores Temporary Data
go to post Vic Sun · Sep 27, 2019 Hello, First of all I wonder what version of Caché you are using as ^MSU has been replaced by ^DATABASE for a long time. That being said, I can't imagine there being any problems with interrupting using ctrl+c. In fact, as you didn't get an <INTERRUPT> error it seems likely that ^MSU/^DATABASE has accounted for a user trying to ctrl+c out and so just returns you to the previous menu.
go to post Vic Sun · Sep 24, 2019 Hello Daniel, As Kenneth mentioned, outside of shadowing/mirroring journaling could still be very important depending on your usage. https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_journal For example, journals are needed in a disaster recovery scenario in order to bring your instance more up to date than the time of the backup itself. If you are not journaling and restore a backup your data will be current as of the time the backup was taken. Replaying journals would be necessary to proceed beyond that. You would only need the journals created after the time of the backup. Also note that I would recommend testing your backup restore procedure and regularly taking integrity checks to confirm the validity of your backups. I would go so far as to say a backup that has not passed an integrity check is not a valid backup. https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_backup
go to post Vic Sun · Sep 20, 2019 While I suspect this is related to the read-only / mirrored-ness of the backup failover member, I would recommend reaching out to the WRC for a more thorough investigation. Alex and Alexey suggested a nice workaround as well.
go to post Vic Sun · Sep 19, 2019 I'm not sure exactly what your steps were - where did you see that error? I have no problem opening objects without locking in a mirrored database on a backup failover member: MIR>s x= ##class(Sample.Person).%OpenId(1,0) MIR>w x1@Sample.Person
go to post Vic Sun · Sep 19, 2019 Hello Vandrei, Your question is a bit vague but hopefully this helps: https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GOBJ_methods ##class(Package.Class).Method(Args)
go to post Vic Sun · Sep 18, 2019 I didn't do a deep dive but presumably the HL7 message is being opened as an object and therefore automatically taking out a shared lock in order to read it.If you really don't care about locking or concurrency protection, I imagine it wouldn't be that difficult to custom code something to do what you want, though you'd probably want to test:https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GOBJ_persobj#GOBJ_concurrency
go to post Vic Sun · Sep 17, 2019 Hello Jeffrey,You're absolutely right that normal read only databases and mirrored databases operate differently. It is not possible to take out locks for a mirrored database on a backup failover member as locks would prevent the member from taking over as primary.If you have a DR async and take out a lock on a mirrored database, then when you try to promote to failover member you'll see a message like this:Unfortunately, that means I don't have a workaround for you unless you have a DR where you can dump the messages instead.Thanks to @Pete Greskoff who I talked to about this behavior.
go to post Vic Sun · Sep 12, 2019 Hello Sergey,Can you confirm if you are getting that kit from the Download Caché button in the sidebar here in the Developer Community? If so, then that alleviates my primary concern that it might actually be a threat.Beyond that, the question would be one of setting up an anti-virus exclusion or disabling it briefly. This is something you might need to do for any software kit that is improperly flagged by your antivirus, which is not really a question of InterSystems technology but of whatever antivirus you are using.Further down the line you may want to add some additional exclusions so Caché can operate properly per this documentation:https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?K...
go to post Vic Sun · Sep 5, 2019 After thinking about this a bit more you could probably use the open command which would be even simpler if you want to output to a file.https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GIOD_iodevcommsex.set file = "</path/to/log/file.txt>"open file:"WNS" use file do $System.OBJ.CompileAll() close file
go to post Vic Sun · Sep 5, 2019 Try using the errlog parameter, something like:w $SYSTEM.OBJ.CompileAll(,.err)https://irisdocs.intersystems.com/healthconnect20191/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25SYSTEM.OBJ#METHOD_CompileAllThen you can pull the errors from the err variable and put it into a file however you want, for example using %Library.File.https://irisdocs.intersystems.com/healthconnect20191/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25Library.FileHope that helps!
go to post Vic Sun · Sep 5, 2019 Hello Scott,Thank you for clarifying. HealthShare Health Connect 2019.1 is built with IRIS so it will not accept a Caché online backup. A CACHE.DAT file can be renamed to IRIS.DAT to be used by IRIS which is documented in the IRIS adoption guide.
go to post Vic Sun · Sep 5, 2019 https://community.intersystems.com/post/health-connect-version-20191-releasedYou need to be on HealthShare core 15.03 or later to take advantage of the in-place conversion for HealthShare Health Connect. I believe HealthShare Health Connect built with Caché 2015.2.2 is not a new enough HealthShare core version.Outside of that, it may be possible to manually convert to InterSystems IRIS but I presume that would be more effort than going through two supported upgrades.