[Peter Heggie]

#following

Peter Heggie

[Peter Heggie]

I am very interested in any responses to your question. We have been struggling with false positives on holidays and wanted a simple way to turn off or turn on sets of alerts that should not be running on a holiday.

We looked at using the AND alert type, to connect a “normal” alert and a holiday alert (which could be a TCL alert that would look at a calendar file and figure out if today was a holiday), but we would need to do this for every normal alert, so we could easily end up with double the number of existing alerts.

i was hoping for an additional function contained in each alert that allows me to callout to a TCL and get a 0 or 1 return code – this would be in additional to all the other attributes of an alert.

So…  you may have to create an alternate alert file that you would load via the command line, that has the right alerts for that holiday.

I think this is the syntax??
<p class=”- topic/p p”>Use this format to run a specific alert. In this example, the alert file is named foo.alert:</p>

<pre class=”+ topic/pre pr-d/codeblock pre codeblock”><code>hcisitectl -s a -A “<var class=”+ topic/keyword sw-d/varname keyword varname”>a</var>=-cl foo.alert”</code></pre>
We played with this once and could not get the command line command to work so hopefully you will figure it out.

Peter Heggie

[Peter Heggie]

We too are grateful for your support and your service to this Cloverleaf Community.

We only go back to 1998 when we used the SNA protocols to connect to the mainframe, to SMS, then Invision. I remember looking on Clovertech for answers and seeing your posts with looong TCL procs… 🙂

We will miss you on the strategy and new offering webinars as well!

Peter

Peter Heggie

[Peter Heggie]

I have not used the HL7 package and I’m notso great with namespaces, but maybe this line:

set hl7 [hl7::parse_msg [msgget $mh]]

it just makes me wonder if it is confusing that you are creating/updating a variable that has the same name as the namespace?

Maybe you use a different variable name:

set hl7msg [hl7::parse_msg [msgget $mh]]

and then change the lines that come after that to use the different variable name:

set MSH_3 [hl7::get_field hl7msg MSH.3]

 

Peter Heggie

[Peter Heggie]

I like that solution Jim!

Peter Heggie

[Peter Heggie]

I’ve never seen or heard of this. Do you have Use Recovery Database enabled?

Peter Heggie

[Peter Heggie]

I was unable to get that to work. I am on cis2022.09.01, on AIX 7.2

On the local site I restarted all processes and the two daemons, and I executed the Refresh Objects command. On the Primary site I ran mktclindex and also edited the TCL proc in the GUI to force the update of the .upocindex file. I ran Refresh Objects there also and I restarted both daemons. I’m still getting the error. I went back to the local site and ran mktclindex but that did not fix the problem.

tcl :out :INFO/0: to_email:11/09/2023 10:33:00] sourceFilter /hci/cis2022.09/integrator/soabattst/tclprocs/email_smtp_mime.tcl: Failed to source filtered file: couldn’t read file “/hci/cis2022.09/integrator/soabattst/tclprocs/email_smtp_mime.tcl”: no such file or directory
[sms :sms :ERR /0: to_email:11/09/2023 10:33:00] Tcl error:
[sms :sms :ERR /0: to_email:–/–/—- –:–:–] msgId = message0
[sms :sms :ERR /0: to_email:–/–/—- –:–:–] proc = ‘extracts_email_send’
[sms :sms :ERR /0: to_email:–/–/—- –:–:–] args = ”
[sms :sms :ERR /0: to_email:–/–/—- –:–:–] result = ”
[sms :sms :ERR /0: to_email:–/–/—- –:–:–] errorInfo: ‘
[sms :sms :ERR /0: to_email:–/–/—- –:–:–] invalid command name “email_smtp_mime”

Just to be clear, the above folder name: /hci/cis2022.09/integrator/soabattst is a link, and all the local sites are in a different file system, with links to them stored in the integrator folder. Our master site is in a sub-folder in the integrator folder (/hci/cis2022.09/integrator/clovertest/<site content>); our local sites are in a different file system (/test/cis2022.09/soabattst/<site content>). Does that make a difference?

 

Now that I have gone through all that and documented the error messages, it just started to work. The only thing I changed was to update the calling proc, in the local site. I don’t know why this made a difference. I looked in the .upocindex file and the tclindex file, in both the local site and Primary Site, and while these were updated at the same time, I don’t actually see the called proc, in the Primary Site, listed in the local site’s upocindex/tclindex files. But the update to the calling proc and the subsequent recycle of that one process which invokes the parent proc seems to have closed the loop. I did not see this activity documented anywhere as required. But nothing else changed.

Peter Heggie

[Peter Heggie]

yes exactly.

I will try Max’s instructions – hopefully I missed something before.

Peter Heggie

[Peter Heggie]

🙂

I really want this to work. We have a few common “subroutine” procs called in multiple sites, just tripped over one this morning, and would really like to end up with one of each..

Peter Heggie

[Peter Heggie]

This is the newer option where you can also define something like a Master site, called a Primary Site, differently for each normal / interface site. So we want to just have one site be the Primary Site for all the interface sites (I know this is just like Master Site. The reason we want to look at using Primary Sites is because we tried using a Master site before but there was a conflict when failing over with HACMP).

My understanding is that Primary Sites function exactly the same as Master Sites, but you don’t set that site at the root level, you set it for each normal site, in the site options.

Peter Heggie

[Peter Heggie]

I am encouraged that you got it to work. I tried putting the called proc ProcB in the Primary Site and the calling proc ProcA is in the current site. When the proc ProcA tries to invoke ProcB, it does not find it.

When you talk about a path for tcl procs, are you talking about physical directory?

I thought I tried every variation of recycling, after moving the called proc ProcB into the Primary Site. First I updated the Site Options of Site A to specify a site (SiteB) as it’s Primary Site. I recycled the host server and then I was able to see the SiteB objects in the SiteA NetConfig and other designers. Then I recycled the process in SiteA which contained the parent proc ProcA.

The invocation of ProcB from ProcA failed due to an unknown command. Maybe there is something else that has to be recycled?

Peter Heggie

[Peter Heggie]

We also are now receiving new “errors” from PDL processing after we upgraded to 2022.09; everything seems to be working so we ignore them.

ex:

[xlt :xlat:WARN/0: c62_xlate:11/07/2023 07:14:57] [0.0.76442748] Delivery to destination thread to_rhio_direct failed. Requeuing msg. iclErr=14
[icl :icl :ERR /0: c62_xlate:11/07/2023 07:14:57] Transport to td ‘to_rhio_direct’ busy

Peter Heggie

[Peter Heggie]

I’m not familiar with this level of debugging with tcp/ip pdl –

• what platform / os level are you on
• is this inbound or outbound; client or server or multi-server
• which PDL are you using
• are you using IPv6/v6, SSL, Close After Write, Driverctl
• are you using Auto re-connect, and/or Delay Connection Until Needed
• do you know what the Keep Alive is on your side, and on the other side?
• is the other side inside your network?

Also, and I know this is probably not a factor, but what trxid type do you use (HL7?), do you have an ACK proc, and what is the OS on the other side?

At first glance it looks like expected packets are not getting received, but I’m not a network expert.

So are you running the same Cloverleaf version in Test and Prod? Is Test on a different OS or OS version? Is it in a different network? This might not be an issue with Cloverleaf.

Peter Heggie

[Peter Heggie]

I don’t know if our firewall issue is your issue, but I can tell you it was not a configuration issue, it was a bug in the firewall software, for a specific version of PaloAlto.

Peter Heggie

[Peter Heggie]

We had a similar issue with our firewall where certain file transfers were killed after X bytes, but only after the connection was quiesced. We had to upgrade our firewall.

Peter Heggie

[Author]

Replies