Your user may have permissions to write a file to the output directory, but that doesn't mean you will have access to all the utilities that pButtons will try to run, including Windows Perfmon. There should definitely be more than 1 log file is a pButtons is running normally.

I wonder if the Buttons report was able to collect its cstats as that also requires elevated permissions. You can check that section within the html report to see if it exists.

I would definitely recommend opening an Administrator Windows command prompt and then navigating to \cacheinstalldir\bin, where you can use "ccontrol console <instancename>" to access the terminal. From there try to run a test pButtons.

What's in the log file? Prior to collection in the html there should be multiple log files containing various pieces of information, so tracking down what is/isn't collecting could be useful.

I suspect OS permissions, can you open a terminal making sure you have administrator privileges so that you can run the proper performance monitoring utilities?

You can just run a test 5 minute run to check if things are running properly.

Hello Duncan,

Please see the following documentation. Defining and Calling Methods.

Some examples:

 do ##class(Package.Class).Method(Args)
 set myval= ##class(Package.Class).Method(Args)
 write ##class(Package.Class).Method(Args) 

You may find some of the courses on learning.intersystems.com (linked in the top bar of the developer community as well) useful such as the Caché Objects Introduction.

Hi Tamara,

The following developer community article may be of use to you:

https://community.intersystems.com/post/how-make-phone-calls-using-cach%C3%A9-objectscript-and-twilio

For text/SMS alerts though you can see the following sample from the developer community:

https://community.intersystems.com/post/simple-text-messaging-alert-using-sms-gateway

There is also an online course Setting Up Alerts to try the text code out.

16384 was the default a long time ago back in Caché 2011, and upgrades would not automatically change this value.

It is a good idea to review your memory settings periodically to make sure they still make sense for your application and usage. This value having never been tweaked from its default may be a sign that other memory values were never thoughtfully adjusted, so the following article may be of use to you (or your team):

https://community.intersystems.com/post/intersystems-data-platforms-and-performance-part-4-looking-memory

Hello Roberto,

I see that my colleague in the WRC has already addressed some of your concerns in the case, but to share some information with the developer community, here are some documentation links that may be useful to understand <STORE> errors:

Low Memory and <STORE> Errors

$zstorage

bbsiz

The first thing I notice is that your $zstorage is set to 16384. This is far below our modern default of 262144 (see bbsiz documentation). Is there a particular reason you would want to modify $zstorage on the fly rather than just have your system-wide setting be higher?

Hello Tamara,

It sounds like you are looking for help getting familiar with Ensemble rather than specifically with the EnsLib.HL7.Operation.FTPOperation. Note that the operation is intended to send out a file from Ensemble to an FTP server, not to ingest a file; if you want to pull in a file from an FTP server to Ensemble you want an FTP Service.

You can find some great starter materials on learning.intersystems.com. You can search for "productions" or "integrations" for some useful courses, but I would recommend "Building Your First HL7 Production." Specifically, I think the sub-course "HL7 I/O: Using HealthShare for Message Transmission" would be very useful.

Some basic documentation is here also:

Adding HL7 Business Operations

Hope that helps! If you have more specific questions feel free to ask.

Please make sure the version you are on is safe to run compaction. See Pete Greskoff's 3 links in this developer community post:

https://community.intersystems.com/post/how-reduce-size-intersystems-cach%C3%A9-database-file-cachedat

In InterSystems IRIS as of 2019.1.0, you have the option to monitor and cancel database tasks such as compaction:

Using Character-based Security Management Routines

^DATABASE

option 15. Show background database tasks
"Displays a list of background tasks that are running or that have run since startup. You can also use this option to re-enter the monitor screen, where you can cancel a currently running task as well as purge the history of completed tasks. (Note that the tasks listed here are not the same as those listed as scheduled tasks in the Task Manager.)"

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.

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.Journal
FreezeOnError


Security.System
DBEncJournal
 

Config.Miscellaneous
IEEEError