Vic Sun · May 26, 2020 go to post

Unfortunately, I'm not aware of anything built-in that can enforce the schema - I think it would be difficult to have this as a preset option because it wouldn't be able to match all use cases. Of course, the ideal would be for the upstream to conform, but that isn't always an option.

I think this will have to be a custom solution, though maybe somebody else can weigh in with some option I've missed. Perhaps somebody has come up with something clever to leverage the schema.

Vic Sun · May 26, 2020 go to post

DefCharEncoding is a setting for HL7 services that you would add the ! to in order to enforce a particular encoding. If MSH:18 is blank then whatever encoding is in DefCharEncoding will be used, whether or not you use ! for the setting. ! in the message in MSH:18 would probably trigger an error as ! doesn't represent a valid encoding.

Vic Sun · May 26, 2020 go to post

Hi Cedric,

It sounds like you are adjusting the messages to have ! in the MSH:18 field. Unless I'm misunderstanding, that seems like a misinterpretation of the DefCharEncoding documentation, which I will include here:

Default Char Encoding

Normally the encoding found in MSH:18 is used, but an "!" at the start of the DefCharEncoding setting will forcibly use whatever encoding you specify.

Hope that helps.

Vic Sun · May 26, 2020 go to post

Hi Elisha,

The general method for handling incoming too-long fields would be the validation setting, which can send a message to the bad message handler to be treated as needed:

Validation

Validating Fields

"Test that field sizes in the message conform to the schema."

In your case if you know what fields need to be truncated it should be really easy to use a DTL to truncate those fields.

Hope that helps!

Vic Sun · May 13, 2020 go to post

Hey Murillo,

I'm not sure how the SOAP stuff you describe works into the standard Ensemble machinery, and understanding what globals/data are not being purged might be useful to provide further guidance. However, the purge you mention is intended for the activity monitor, and is not the main purge task which is just Ens.Util.Tasks.Purge. See the following docs:

Purging Production Data

Monitoring Activity Volume

Vic Sun · May 11, 2020 go to post

Hi Laura,

I don't really have an answer but maybe you can include some pseudo-code or sample code for people to try to reproduce the behavior you're describing. I have an idea of what you're doing from your description but the specifics could be important.

Vic Sun · May 7, 2020 go to post

I think the WRC should be able to help out with this - definitely seems like an odd issue worth investigating.

Vic Sun · May 7, 2020 go to post

Hi Russell,

Can you share more of how you're trying to use %Net.SSH.Session and where exactly the error is coming up? Your version information may be useful as well.

Vic Sun · May 6, 2020 go to post

Hello,

I'm able to reproduce the behavior with emergency mode requiring you to enter the emergency mode user/pass to shut down. You are certainly welcome to reach out to the WRC to confirm if this is intended behavior, but I suspect that it is. I am wondering what the use case is here as emergency access mode is a special mode, intended for use "under certain dire circumstances, such as if there is severe damage to security configuration information or if no users with the %Admin_Manage:Use or %Admin_Security:Use privileges are available". In those situations you would be taking manual steps so uninteractive shut down would not be necessary.

Could you simply use a normal login and not emergency mode?

Vic Sun · Apr 29, 2020 go to post

The other commenters have good suggestions but I would recommend additionally collecting a pButtons to compare. Try and determine if there are any differences other than OS - hardware, memory configuration, global mappings, or anything else. We want to make sure we're comparing apples to apples! If everything seems to be the same, then you could reach out to the WRC who can help investigate this further.

Vic Sun · Apr 27, 2020 go to post

As far as I know I don't think this behavior has changed in 2020. While I was testing the monitor myself recently I noticed the dropdowns getting cleared but when I saw that auto-refresh was disabled in newer versions I didn't  think I needed to follow up on this. If you disable the refresh global you'll find that the tagline of 60s refresh no longer appears as well.

If you really felt this was worth changing I'd recommend that you reach out to your ISC representative (or the WRC) but I would be prepared for the response that the monitor is not intended to be a complete solution. That is not to say that a change to help alleviate the behavior are seeing would not be considered, so if this is really tripping you up it would be worth reporting - maybe others have the same pain and there's enough momentum to get this addressed.

You may find the following article useful in terms of building your own monitoring solution.

https://community.intersystems.com/post/monitoring-intersystems-iris-using-built-rest-api

Hope that helps.

Vic Sun · Apr 27, 2020 go to post

Hello Julian,

The default behavior in your version would be for the activity monitor page to not auto-refresh, but I saw in one of your posts that you have enabled SMP auto-refresh.

https://community.intersystems.com/post/queues-refresh-iris-20191

The activity monitor dashboard is really just a starting point - once you start collecting data using the activity monitor you can easily access the monitor tables such as ens_activity_data.days with SQL.

Vic Sun · Apr 17, 2020 go to post

Hi Julian,

You're using curly brackets rather than parentheses at the outermost level. If that still presents an issue I'd recommend adding some traces to see what's actually getting referenced.

Vic Sun · Apr 17, 2020 go to post

Hi Julian,

You could do this with a custom Ensemble utility function but from your description I think parenthesis syntax should work just fine.

Defining Custom Utility Functions

Parenthesis () Syntax

HL7.(PIDgrpgrp(1).ORCgrp().OBR:UniversalServiceIdentifier.identifier) should return a concatenated string from looping through the ORCgrps - you could then search that string to find the value you are looking for.

Hope that helps!

Vic Sun · Apr 17, 2020 go to post

I second Robert's recommendation to check the lock table. It is probably best to understand what else is holding the lock than to just try and release the lock - the lock might be there for a reason, and if not you should look into what is taking it out and why.

Oliver's suggestion to verify that the lock table isn't full is also a good one.

Vic Sun · Apr 15, 2020 go to post

Hi Jordan,

Check out the docs on private/public variables here:

Callable User-defined Code Modules

Variables

You can pass the variable to the subroutine as a parameter or declare it a public variable - my guess it passing it as a parameter would be the "safer" option.

Vic Sun · Apr 14, 2020 go to post

Hello Eric,

This message indicates that an Ensemble job had unexpectedly terminated. I would recommend checking OS logs or looking for other events that could have triggered a process termination outside of Ensemble.

Vic Sun · Apr 7, 2020 go to post

Cristiano has a good suggestion but this issue could also depend on the various settings. You've censored pretty much everything so it's difficult to troubleshoot.

Vic Sun · Apr 6, 2020 go to post

FileList was likely found in the EnsLib.FTP.Common class reference. This is the class extended by EnsLib.FTP.OutboundAdapter. I suspect that could work also - see above documented syntax for running the query.

Hope that helps!

Vic Sun · Apr 6, 2020 go to post

Hi Michael,

I assume you were looking at the %Library.File documentation for FileListFetch. FileListFetch is not meant to be used directly, but is a part of a class query which can be used as documented here:

Defining and Using Class Queries

https://cedocs.intersystems.com/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25Library.File

If you can navigate to the directory then you could use ##class(%Library.File).GetFileSize(), however for a remote FTP server this probably wouldn't work. You would want to use %Net.SSH.SFTP as documented here:

Using SSH

https://cedocs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?APP=1&CLASSNAME=%25Net.SSH.SFTP

edit: the FileList query is not in %Library.File - I am not sure where that query comes from but the rest of my post remains revelant

Vic Sun · Apr 4, 2020 go to post

Is there any reason you need to run these scripts from a shell script? That would definitely be possible and there are plenty of examples you can find on the community with a bit of searching, but I think it would be quite simple to do this in Object Script.

Vic Sun · Apr 2, 2020 go to post

Hi Augusto,

The role that handles backups is %Admin_Operate as documented here:

Assets and Resources

I don't believe there is a resource that specifically governs the external freeze/thaw capability, you would probably need to design something custom for that particular restriction. For example, you might assign your user a startup namespace or routine as documented here:

Users

Startup Namespace    The namespace in which to begin execution following login from a terminal-type service or the Portal. This property overrides any namespace value provided via the command invoking Caché.


Startup Tag^Routine    The routine to execute automatically following login from a terminal-type service. This property overrides any routine value provided via the command invoking Caché.

Vic Sun · Apr 1, 2020 go to post

Hi Kevin,

Thanks for pointing the documentation issue out. The documentation has been modified to specify that the <NETWORK DATA UPDATE FAILED - MAXSTRING> error relates to network activity - "An asynchronous network error occurred and updates sent over the network were lost because InterSystems IRIS/Caché on the server has encountered an attempt to specify or create a data string longer than the implementation allows (32,767 characters)."

What were your instances doing at the time you received this error and where did you find this error? I put a little time into trying to throw this error myself by manipulating some large strings from an ECP app server but wasn't able to reproduce it.

Vic Sun · Mar 31, 2020 go to post

Happy to help! For what it's worth, best practice to initiate a failover would be to simply cleanly shut down the primary.