[Hope Rolens]

Daniel,

thanks for the reply.  If by some miracle I come across a definitive answer on the use of interface engines for CCD documents for future stages, I’ll post it on Clovertech.

[Hope Rolens]

From reading this post, I am of the understanding that using Cloverleaf version 5.7 to pass CCD documents between systems has been done by other Lawson clients.

But I was wondering if using Cloverleaf 5.7 to move CCD data between other ‘CCD certified’ systems meets the certification requirements.

I’ve not been able to find a definitive answer (or at least an intelligible answer) so far.  Hoping someone from this forum could help.

Thanks,

Hope Schnelten

Hospital Sisters Health Systems

Springfield, Illinois

[Hope Rolens]

Thanks, Jim.  

I emailed the remote system’s network admin guy, to see if they can release the port.  We agree that the admins of the VPN/firewall should fix the problem, but cannot count on that happening.

We haven’t ruled out simply bouncing the thread via a ksh script scheduled in cron, or through a qdx alert.  But the other options will be discussed with the vendor, and we’ll settle on one.

thanks again to everyone who responded to this post.

Hope

[Hope Rolens]

Thanks Charlie and Chris,

we’re going to get with the vendor system’s Cloverleaf programmer and hash out the options.  

Hope

[Hope Rolens]

Hi Charlie,

I have read that using Muli-Server can solve this problem in some of the other posts.  However, I’m concerned that this will create a new connection but leave the “hung/stale” connection out there.  Am I thinking correctly about this?  Or, will Cloverleaf or the OS eventually time-out and close the previous TCP connection that was dropped by the vendor Firewall?

The vendor Firewall closes the connection after one hour of inactivity.  We only plan to receive one or two message per day on this connection, so I’m worried we have the potential of creating over 20 hung/stale TCP connections on our server each day.

Thanks,

[Hope Rolens]

Jim,

in your response, you mentioned the Close After Write protocol option, and other posts involving problems with VPN’s.

We are receiving results from another Cloverleaf engine through a VPN, which closes the connection after 1 hour of inactivity.  The result is that our inbound thinks it’s still connected, while their outbound goes to Opening.  The administrators of the VPN are not willing to change the timeout. If Close After Write is checked on the outbound thread on the other engine, will that resolve the problem?

I haven’t seen it mentioned as a resolution in the other postings about VPN connection issues, so am wondering if it will work.  (Our other option is a script to periodically bounce the connection on our end, which seems to restore the connection)

Thanks,

Hope Schnelten

Hospital Sisters Health Systems

Springfield, Illinois

hschnelt@ccc.hshs.org

217-492-2268

[Hope Rolens]

Charlie,

I’m calling a tcl proc to shut down the process using the system command:

 set stopProc [catch [system hcienginestop -p $process]]

Then in shutdown mode, a different tcl proc is kicked off in the background to start the process when certain conditions are met:

     shutdown {

        echo “starting shutdown mode”

       # check to see if variable stopProc exists.  If = 1, run proc to monitor dr and start process.  If != 1, shut down as  usual

        if {[info exists stopProc]} {

           if {$stopProc == “1”} {

               set stopProc 0

exec /qdxtest/qdx5.7/integrator/bin/tcl /qdxtest/qdx5.7/integrator/msjsf2/tclprocs/lib/drdb_startProcess.tcl $HciSite $HciProcess $gmsh11 &

               return “”

           }

        }

     }

Everything seems to be working fine — the process stops with the expected error and warning (see end).  

Echos in the proc that kicks off when the process shuts down continue to write to the process log.  Do you think writing anything to the log after the process has shut down will be problematic ?

Thanks,    — Hope

[icl :tcpi:ERR /0:  A59Tphi_cmd:08/02/2010 08:55:43] write failed: Broken pipe

[prod:prod:INFO/0:     TRphiITS:08/02/2010 08:55:43] Checking for leaked handles in the TPS interpreter…

Handle     Allocated by

======     ============

message0  

WARNING: Message [0.0.1104375] is in the RDB and was left bound into Tcl

[Hope Rolens]

Thank you, Charlie.  I appreciate your help!  –Hope

[Hope Rolens]

Charlie,

I’m working on a tps pre-proc to stop a process when certain conditions are met.  I want to keep the current message in the recovery database, but haven’t figured out how to do so without creating broken pipes and/or leaked handles in the TPS interpreter.  

This happens when I use return 0 to exit the proc (after issuing the hcienginestop command).   The only displist I know to return without causing errors is the ERROR $mh.  But I’d rather the message not go to the Error db.

Any suggestions?

Thanks,

Hope Schnelten

Hospital Sisters Health Systems

[Author]

Replies