regexp error in engine but not testing tool

[David Burgess]

I’ve run into a real head scratcher.  I have isolated the problem to a single regexp command.  I even reduced the run section of the proc to the following six lines

Code:

keylget args MSGID mh
set msg [msgget $mh]
set foundSegList “MSH PID PV1 IN1 GT1 ORC OBR”
set segOrderRegEx {^((MSH PID){1}( NTE){0,10}( NK1){0,1}( PV1){0,1}?( ZCC){0,1}( IN1){0,2}?(( GT1){0,1}?( DG1){0,120}?)( ZCI)?(((( ORC OBR)( OBX){0,}( NTE){0,}){1,40}))) $}
set x [regexp $segOrderRegEx $foundSegList]            
lappend dispList “CONTINUE $mh”

I’ll grant you the lines are ugly, but there is nothing wrong with them.  They function perfectly in the testing tool.  However, when I try to run this in the engine (as an inbound TPS) I get a core dump.  We are currently running cloverleaf 5.7 in an AIX environment (ver 6.1 tech level 6).  Anyone have any ideas?  (I think I can break up the regexp as a work around, but I want to understand how the testing tool differs from the engine run time.)

Thank you all in advance for you time and consideration!

Topic

[Chris Williams]

David,

I’m not sure what you are expecting to have the regexp return in the given conditions, but I can guess. If you remove the msg and mh statements and just run the regexp part thru hcitcl, you change the result based on the existence of the space at the end of segOrderRegEx. You are anchoring both at the beginning of the line and at the end AFTER that space. With the trailing space, regexp returns 0 because foundSegList doesn’t end with a space. Without the space it returns 1. However, that probably doesn’t answer your question about your core dump and differences in the testing tool.

[Elisha Gould]

My guess would be that the crash isn’t caused by that statement directly.

Cloverleaf has some bugs that I’ve noticed in 5.8 with concurrency and sometimes runs into race conditions. It may be these issues are in 5.7 as well.

Does the site have multiple inbound/outbound threads having activity when the issue occurs? If so it may be a concurrency issue.

Another thing to check is how long it takes for the script to execute. I know in the start portion for 5.8, there was an issue that I came across where the site would crash if it took longer than a few hundred milliseconds, which has since been fixed.

Out of curisity, what does the log show for the “PANIC:” lines?

If its reproducable, best to get an example together and log a call for Infor to look at.

[Max Drown (Infor)]

David, I suspect that you may need to escape those curly braces or re-write the expression without using them.

-- Max Drown (Infor)

[Charlie Bursell]

The braces are already removed by the set statement

set segOrderRegEx {^((MSH PID){1}( NTE){0,10}( NK1){0,1}( PV1){0,1}?( ZCC){0,1}( IN1){0,2}?(( GT1){0,1}?( DG1){0,120}?)( ZCI)?(((( ORC OBR)( OBX){0,}( NTE){0,}){1,40}))) $}

echo $setOrderRegEx

^((MSH PID){1}( NTE){0,10}( NK1){0,1}( PV1){0,1}?( ZCC){0,1}( IN1){0,2}?(( GT1){0,1}?( DG1){0,120}?)( ZCI)?(((( ORC OBR)( OBX){0,}( NTE){0,}){1,40}))) $

You could try it like:  set x [regexp [subst $segOrderRegEx] $foundSegList]

Even though you say this does not abort outside of the engine I don’t see hoe it would ever return anything but false (0)

The question mak after the expression {m,n} makes it look for the minumum which is 0.  Some of the grouings do not make sense

Why not tell us what you are trying to do rather than try to debug a problem in the engine with an expression that makes no sense?

[David Young]

Hi Charlie, et al.–

What I was trying to create was a RegEx that would evaluate the list of segments found (variable foundSegList) in an order message and then report back if any required segments are missing or out of sequence or any optional or conditional segments are out of order (based on my RegEx stored in segOrderRegEx). This works just fine in a standalone Tcl Proc (Tclx package required).

The expression I used is in the manual Tcl proc after capturing the values is:

   if { [regexp $segOrderRegEx $foundSegList] }

So, I was trying to do the same ORM message validation in a TPS Inbound Pre-Proc to evaluate and validate incoming ORM messages. During testing in the Cloverleaf Testing Tool for some reason the variable holding the list of found segments was adding a space at the end of the list and the RegEx was failing (return 0) no matter what segments/order was included, so to get beyond that I added the space to the the RegEx figuring I could tackle that issue later; in the Testing Tool it was then successfully evaluating messages and catching both passing sequences (return 1) and failing sequences (return 0), but I knew I’d have to return to the extra space later… I put the TPS Proc into a test thread and it began core dumping.

The RegEx is captured through a KEYS file that I open and pull the contents into (to faciliate updating a KEYS (keyed list file) file rather than the code itself) which is why the entire RegEx is quoted with curly braces which are then removed leaving me with what I need. Looks something like this in the file now (a few extraneous items removed):

****************

{SEGREGEX {^((MSH PID){1}( NTE){0,10}( NK1){0,1}( PV1){0,1}( ZCC){0,1}( IN1){0,2}(( GT1){0,1}( DG1){0,120})( ZCI){0,1}(((( ORC OBR)( OBX){0,}( NTE){0,}){1,40})))$}}

…

keylget segKeys SEGREGEX segOrderRegEx

****************

I have removed all the uneccessary question marks and the space, so now I have something like this:

^((MSH PID){1}( NTE){0,10}( NK1){0,1}( PV1){0,1}( ZCC){0,1}( IN1){0,2}(( GT1){0,1}( DG1){0,120})( ZCI){0,1}(((( ORC OBR)( OBX){0,}( NTE){0,}){1,40})))$

Is there a better way to get a list of segments in a message and then iterate through that list to validate the sequence is proper and incorporates all required and optional segments? Additionally, I’d like to then store the offending segments and return them in a message I email out (I already have that piece in place if I can stop the core dumps).

Thanks very much for your time!

Dave Young

David Young, AKA, TeflonSuper
Just because one can do a thing does not mean one should do a thing.

[Charlie Bursell]

regular expressions are not always a good tool when dealing with lists

However we can sometimes break out rule to always treat lists as lists and strings as strings as long as we know what we are doing

Assume you check list is like

set check

[Author]

Replies