[Charlie Bursell]

Just issue the exec call and do nothing after.  If you return the engine might try to deliver another message.

What do you mean by the hook? I am not saying to interrogate the Error Database via a proc.  Once the process and the thread is shutdown, I am sure there will be some manual intervention before restarting.  At that time you can manually clear any database issues.

[Charlie Bursell]

I have always created a shell script which I placed in the site scripts directory so it is the path and then put the hicienginestop command in there to run in the background.

When you exec this from the engine you must make sure the process does not receive any more messages since the stop command may take a while.  You can do this by just not returning from the proc.  You will have to take care of messages in the database afterwards.

[Charlie Bursell]

What you really seem to want is the second iteration of the PID.3 field, not the second value.
Is it always this way?  If so, simply copy the second iteration of PID.3 to PID.3.
If not you need some method to ascertain if there is a second iteration.  What do you do then?

[Charlie Bursell]

I agree with Jason.  More complex data structures are best handled with dictionary.  Arrays are nice if not too complex.

[Charlie Bursell]

I made a mistake.  The msgcopy should be inside the loop.  msgcopy will give you a new message handle for each message while maintaining the original metadata.

To make it better, if he original message was large, after getting the data from the original message handle you could do something “msgset $mh “.  That way you are not copying the data with each msgcopy, only the metadata.   Note the original message handle is killed since it contains nothing needed after the loop.

 

I hope this makes sense.

[Charlie Bursell]

Read each file into a list.  When the list is complete:

set dispList {“KILL $mh”}
set nmh msgcopy [msgcopy $mh]

foreach fn $files {
msgset $nmh $fn
lappend dispList {“CONTINUE $nmh”}
}

Return $displist

[Charlie Bursell]

Sorry I misunderstood the problem.

For the above you need to have three array elements:  OrderNo, AccNo and Code.  Then make each a list . As you parse a value,  lassign it to the proper array element as needed.

Other than this I would need to see your proc.

[Charlie Bursell]

Take a look at tclXML package available here: https://tclxml.sourceforge.net/tclxml.html

It is for rudimentary parsing.  If you need more look for he Tcl DOM package.

If simple XML and you have a priori knowledge of the layout it can be done quite nicely with regular expressions.

For some reason, regex scares the hell out of some but it is very powerful if you learn to use it.

 

[Charlie Bursell]

If you put the threads accessing the database in the same process you can use Tcl global values or even a namespace since they would all be using the same Tcl interpreter.

 

Just a thought

[Charlie Bursell]

Peg

I tried send the proc tour email but it bounced.  Any ideas.  Maybe change the suffix?

I tied uploading it to the forums as .htc suffix and then again as .txt and was rejected each time

Has anyone had any luck uploading a proc to the forum?

[Charlie Bursell]

The operative question is why?  HL7 is an ASCII protocol

[Charlie Bursell]

Now it won’t even let me up .txt files.  Send me an email and I will send to you

[Charlie Bursell]

This the latest.  Note it is .txt so it will upload.  Change to .htc for Windows or just remove .txt if Unix and make it executable

I sally put it in contrib directory so I have a path.

[Charlie Bursell]

Everybody has an opinion I might as well too. 🙂   I like regular expressions.

set dt 20250305

regsub — {(\d{4})(\d{4})} $dt {\2\1} newdt

echo $newdt  ==> 03052025

The beauty of TCL is there are several ways to do the same thing

[Charlie Bursell]

Jim is right.  It is best to edit directly if for some reason you do not want to use the GUI.  But be sure to BACKUP!  Never know when you will fat finger something.

The change will require restart any way so no need to automate too much.

[Author]

Replies