@tim-wanner
Forum Replies Created
-
AuthorReplies
-
We had tried this code with a recommendation from IBM, with no success, until we applied the latest software updates to 6.1 AIX. We are still in POC stage but it appears this is the answer. We are able to alloc up to a gig to a particular process. You have to use a switch to designate shared memory, but this is great stuff.. Thanks Russ for the post.
We currently have 5.8.5 on a test server only, but I’m throwing my 2 cents in on this. We have some sites with 80 to 90 interfaces, and it’s impossible read the names. Technical Support says I have to live with the errors, becacuse PING is not configured to return the IP address without the -s switch in our environment. It seems to me that would hold true in most UNIX environments. We need to be able to adjust Cloverleaf rather than reconfigure our network. The errors did not appear prior to 5.7. I collected the server names and IP’s and will add to the etc/hosts file on Monday. Thanks for the quick response. We are using a UNIX environment, and in the error log of every process are these errors.
The threads all connect to these servers, yet the errors remain in the log.
This particualr site has 55 interfaces yet anly these few report a connection error
ps97recycle_out Protocol PDL TCP/IP Host: cannot find host ‘mercury.carenet.org’
ps21ec62_out Protocol PDL TCP/IP Host: cannot find host ‘fenix.carenet.org’
ps64dl35_out Protocol PDL TCP/IP Host: cannot find host ‘saturn.carenet.org’
ps6ec70_out Protocol PDL TCP/IP Host: cannot find host ‘fenix.carenet.org’
ps1cop16_out Protocol PDL TCP/IP Host: cannot find host ‘fenix.carenet.org’
ps21lipk_out Protocol PDL TCP/IP Host: cannot find host ‘fenix.carenet.org’
ps64dx70_out Protocol PDL TCP/IP Host: cannot find host ‘saturn.carenet.org’
ps65hpf_out Protocol PDL TCP/IP Host: cannot find host ‘mercury.carenet.org’
ps12prov_out Protocol PDL TCP/IP Host: cannot find host ‘mbhsgiint01.carenet.org’
ps1msc26_out Protocol PDL TCP/IP Host: cannot find host ‘fenix.carenet.org’
The STAR team is pursuing this method. Thanks for your responses.
Tim
From: hisnet@googlegroups.com [mailto:hisnet@googlegroups.com] On Behalf
Of Beall, Jim
Sent: Tuesday, September 22, 2009 07:41
Subject: RE: Series Patient Auto Discharge/Readmit at End of Month
Question
There’s a fairly common customization to the series discharge/re-reg
process you can request that pauses the process every so often for a few
seconds to let other transactions (such as orders and new registrations)
go through. We have it here.
I don’t remember the specifics (how often the process pauses or how long
it waits) but its impact on the issue you describe was significant. It
will cost you – at least it cost us when we requested it in 2005 – but
it’s worth it.
Jim Beall, Sr. Programmer Analyst
Columbus Regional Hospital
Columbus, Indiana
(812) 376-5018
P Please consider the environment before printing this email
Original Message
From: hisnet@googlegroups.com [mailto:hisnet@googlegroups.com] On Behalf
Of Tina Carroll
Sent: Monday, September 21, 2009 6:22 PM
To: hisnet
Subject: Series Patient Auto Discharge/Readmit at End of Month Question
January 31, 2009 at 4:58 pm in reply to: Passing really long (over 100K) messages through the engine #66722Cloverleaf 5.5 and below. When setting up variants, there is a 100K limit on the size of a field, this was causing our ENCODED documents in the OBX segment to be chopped causing decoding issues. You cannot increase the size through the GUI, but if you edit the “fields” file in the variant directory, you can increase this size with SUCCESS. *** Important to note though, if you edit the variant again in the GUI, even if you do not touch that field, it will revert back to an eratic size.
We’ve done minimal testing with 5.6 because of other priorities. Created sites, threads, passed untranslated messages.
So far no anomalies, but we’re proceeding with caution.
The problem stemmed from using ZFS file system on SUN. There is a setting in /hcisite/ecec/database/rdm.ini “truename=0” From HV R&D:
Looking at the mnttab files confirmed that the problem is that the
Raima database’s truename functionality does not handle ZFS
configuration for the Cloverleaf directories well. Like the case
reproduced in our lab, the fsname does not match the profiles expected
by Raima’s truename code.
zp1/quovadx /opt/hci/quovadx zfs
rw,devices,setuid,exec,xattr,atime,dev=4010004 1216129002
We will follow up on this issue with Birdstep and hopefully they will
address it in a future release.
Until then, we now know that with certain file systems and
configurations the truename flag needs to be turned off in rdm.ini.
Tim
hl7_sndr: Portnum is required and must be > 1024 Usage: hl7_sndr -r portnum -f filename
-b burstno -n nodenm -w t_delay
where: portnum – is the tcp port number to use
filename- is the filename to read data from
burstno – number trans to send before wait
nodenm – name of node to connect to
t_delay – delay in seconds between batches
hl7_rcvr: Portnum is required and should be > 1024 Usage: hl7_rcvr -p portnum -f filename -[c|a]
-e ae_freq -r ar_freq -w ack_dly -m ack_dly_type
where: portnum – is the tcp port number to use
-c|a – commit or application ack’s
filename – is the filename to store data in
ae_freq – frequency to send AE NAKs
ar_freq – frequency to send AR NAKs
ack_dly – delay in seconds before AA ACKs
ack_dly_type – HL7 msg type to delay on
This was recommended by support: Hi Tim, make a copy of the mlp_tcp.pdl, modify the mlp_tcp.pdl like the following below, and then compile the pdl:
…
hci_pd_msg_style basic phrase:basic-msg
field:data
timeout:60000
resync:\xb
Unix Sun server with v10 Solaris, and v 5.5 Clovleaf. Does anyone know the correctsettings for Solaris 10? These are the default settings, but do not work with Cloverleaf. semmni = 8192
semmsl = default (512)
semopm = default (512)
semmns = obsolete
No. I know the Cloverleaf thread was not dropping, and couldn’t prove that the STAR interface was not. We use a series of monitoring scripts, so I added one to bounce the process every 3 hours from 8:00 PM until 8:00 AM. Since it was a scheduling interface, it was idle after hours. Problem has not returned. -
AuthorReplies
