@dick-bly
Forum Replies Created
-
AuthorReplies
-
Michael, you can put a thread on hold from an inbound reply, but in order to start the data flowing again you must stop and start the thread. DO NOT release the hold with the GUI or the message that caused the hold will not be sebt until the thread is cycled. do the KILL on the reply instead of the KILLREPLY to keep any further messages from being sent, then exec the hcicmd in the background using & at the end of the line to put the thread on hold. the thread will stop sending because of the KILL and then go to hold state. will work on unix and windows.
The problem is realy in the qdxservice – it has a built in limit. you can start a process using the -n option ( bypass the service) but doing so outside of the context of the service will cause the process to die when the user signs off.
the work around that I have used is to create an alert that starts the process if dead, using the -n option. This starts the process in the context of the service but not running under the service. works, no limitations.
this limitation is supposed to be removed sometime in the future.
My two cents – Those that know me may think I hate windows, and they are probably right. The reliablility of cloverleaf on windows is poor to say the least (quovadx will tell you otherwise, but talk to the customer base.) If you have a limited number of interfaces, use only the tools supplied by qdx, don’t schedule task, etc., and can afford to reboot weekly, and don’t neeed a backup system, then you could get by with it. Do watch out for the windows pacthes, they have been known to break applications.
Plain and simple – cloverleaf was built on to run on unix (aix in particular)
The ports to other unix/unix like systems is easir to do than than trying to prot to windows where things are done differently. If you have multiple sites on a system, they have to run under one windows service, one database manager, and have a common point of failure that will take down all of your sites. Cuirrently under cl 5.3 and windows server 2003 there are major problems with shell and tcl interaction. In fact, from a shell, start hcitcl several time and you are likely to see it fail to even run, giving very little information about why. It is a constant battle.
we had work arounds that seemd to work on running tcl script (redirects) but when one of the recent windows patches went in, the scripts started failing.
If you want to run windows, then use a product that was designed for windows and its pitfalls. If you want to run cloverleaf (best choice in my book) then do it on unix. You’ll be a lot happier.
try putting a : between the hour and minute try using the line break sequence John, due to that issue, I never use the gui or hcicmd to cycle smat files. Instead I have a script that does that for me. It reads the netconfig to find the smat files and then if there any “old” files renames them with a timestamp and suffix that increments if a file already exists with that name. It then does the cycle save (based on what is in the netconfig) and goes thru the renaming process again. It will operate on all connections in a site or a single specified connection. The current vesion also moves the renamed files to the site dir to a savedmsgs dir to its assoctiated thread name dir so that all saved messages for thread1 would be in the directory
$HCISITEDIR/savedmsgs/thread1
CAUTION !! xlateInVals/xlateOutVals are lists and should always be treated as such. Failure to do so can and will someday come back to bite you in the butt. Using shortcuts because you think you knwo what the data will always be is a very dangerous thing to do. That said, if you are doing a string trim on a variable and only one item was passed then set xlateOutVals
redirect should be done on both stdout and stderr and a catch should be used as in if [catch { exec abc 2>nul: 1> nul: } err] {
#error handling code
}
without this kind of code it will intemittently hang. cl 5.3/ windows
dont forget cmds like set and eval to perform functions on accessing variables for example you know that set x [set y] would be the equiv of set x $y but you can also do set z 20;set y z ; set x [set $y]. now x has the vaue of 20. eval comes in handy when you need to do things like
set x ${$name}(z)
for example
tcl>set ary(x) 3
tcl>set y ary
tcl>echo ${$y}(x) ;# attempt to use $y as an array name
Error: can’t read “$y”: no such varibale
tcl>
tcl>echo $[set y](x) an attemt to echo the value
$ary(x)
an eval completes the reference
tcl>eval echo $[set y](x)
3
tcl>
and then you could do
tcl>echo $$y(x)
Error: can’t read “y(x)”: variable isn’t array
tcl>echo $${y}(x)
$ary(x)
which then leads to
tcl>eval echo $${y}(x)
3
shell out to a secondary process that sets the environment to each site and do an msiAttach while in that sub shells tcl scripts, returning the data to the controlling script. while you can do an msiAttach to the shared mem region for a site, they left out the msiDetach so the only way to do so is to end the process.
An example of no forethought.
The fix is to write your inbound tps that creates the ack not to do it if the messages has a status of resend. You could also not send an ack if the priority is greater than the default priority of 5120 and always do your resend with a priority of 6000 I for one would not recommend acking from within a pdl. It leaves a window open that could prevent the incoming message from getting into the rdb should a problem occur. Acking from the inbound tps stack assures that the message is without question in the rdb as it is put there after ther the pdl and before the tps runs. The acks should be application to application, not driver to driver or driver to application. -
AuthorReplies
