Cloverleaf error: no match-no more phrases to try

[Ariba Jones]

I am testing an interface and am receiving an error message that I don’t understand.  I have tested this interface within the last two weeks and it worked fine.  I received messages from the sending system on this inbound thread.  The inbound thread is setup as tcp/ip.  The sending system did do some work on it’s side and turned off the interface while that was being done.  Now that I am trying to test this interface again, it is not working.  I can ping the sending system’s ip from the engine.  I have not changed anything in the configurator for this interface.  The sending system can see the files get generated and say that it looks like the file is being sent to the engine.  When I look at the error log for the process it says: 06/21/2005 10:22:25 [pdl :PDL :ERR /0:   dbs_chg_in] no-match: no more phrases to try.  Does anyone know what this error message means???  I do not receive the messages.  I am in the middle of an upgrade and need this to work ASAP!

Thanks, Ariba

Topic

[David Caragay]

Ariba,

Sounds like your inbound thread protocol is receiving but it’s in a format it does not understand.  Check your protocol pdl.  Are you using mlp_tcp.pdl?  It may need  to be configured in the inbound thread definition.  You stated that you are using the tcpip protocol but you may need to use pdl-tcpip instead.  If it worked in before, ask the vendor if they change the inbound msg.  The vendor may have them configured differently.  Compare the before and after inbound msg in hex to really see what has changed.

[Ariba Jones]

David,

I have checked my configuration settings.  I do have PROTOCOL:pdl-tcpip.  I also have PDL: mlp_tcp.pdl.  I need to ask whether the file has changed.  How can I do a before and after if I do not see the message that was sent today?  Where would I find it?  I don’t see anything in the error database or recovery database.

Ariba

[Rick Brown]

I did a quick search in the forum and this question has been answered.

Take a peek here:

https://usspvlclovertch2.infor.com/viewtopic.php?t=336&highlight=match

I hope this helps.

[David Garcia]

I’m having an intermittent “no-match” problem with a Horizon lab interface that has been live for a couple of years. When the error occurs, the interface hangs in the lab system and has to be reset manually. I set up an EO alias to enable all output for the pdl and applied it to the thread.

I’m a little puzzled by the pdl output. In some cases the inbound message doesn’t arrive all at once. It looks as if the pdl waits 15 seconds for the rest of the message to appear:

Quote:

[pdl :read:DBUG/2:     pwlab_in] Events: E 0, R 8, W 0

[pdl :PDL :DBUG/0:     pwlab_in] read 512 bytes

[pdl :PDL :DBUG/0:     pwlab_in] input buffer accepted 512 bytes, now 512

[pdl :PDL :DBUG/0:     pwlab_in]  0b 4d 53 48  7c 5e 7e 5c  |.MSH|^~|

[pdl :PDL :DBUG/0:     pwlab_in]  26 7c 4c 41  30 31 7c 4c  |&|LA01|L|

— snip —

[pdl :PDL :DBUG/0:     pwlab_in]  20 54 4f 50  20 35 20 4d  | TOP 5 M|

[pdl :PDL :DBUG/0:     pwlab_in]  4c 7c 30 30  30 36 34 37  |L|000647|

[pdl :PDL :DBUG/0:     pwlab_in] IDLE and 512 bytes but no error: starting READ

[pdl :PDL :DBUG/2:     pwlab_in] PDL changed states: old 0, new 1

[pdl :PDL :DBUG/0:     pwlab_in] Calling Tcl procedure: hci_pd.read

[pdl :PDL :DBUG/0:     pwlab_in] with args: {}

[pdl :PDL :DBUG/0:     pwlab_in] Tcl procedure hci_pd.read returns ‘RECEIVE’

[pdl :PDL :DBUG/0:     pwlab_in] trying to match phrase: basic-msg

[pdl :PDL :DBUG/1:     pwlab_in] PDL setting timeout in 15.00 seconds

[pdl :PDL :DBUG/0:     pwlab_in] READ operation in progress (512 bytes buffered still, 512 before)

[pdl :read:DBUG/2:     pwlab_in] Events: E 0, R 8, W 0

[pdl :PDL :DBUG/0:     pwlab_in] read 455 bytes

[pdl :PDL :DBUG/0:     pwlab_in] input buffer accepted 455 bytes, now 967

[pdl :PDL :DBUG/0:     pwlab_in]  5e 44 45 41  52 42 4f 52  |^DEARBOR|

[pdl :PDL :DBUG/0:     pwlab_in]  4e 5e 4a 54  7c 7c 7c 7c  |N^JT|||||

— snip —

[pdl :PDL :DBUG/0:     pwlab_in]  20 35 3a 34  36 3a 31 34  | 5:46:14|

[pdl :PDL :DBUG/0:     pwlab_in]  20 50 4d 24  0d 1c 0d     | PM$…|

[pdl :PDL :DBUG/0:     pwlab_in] multi_phrase_2: status = ok

[pdl :PDL :DBUG/0:     pwlab_in] Calling Tcl procedure: read.done

[pdl :PDL :DBUG/0:     pwlab_in] with args: {{status ok} {end {967 0}} {data {1 964}}}

[pdl :PDL :DBUG/0:     pwlab_in] Tcl procedure read.done returns ”

[pdl :PDL :DBUG/2:     pwlab_in] PDL changed states: old 1, new 0

[pdl :read:DBUG/1:     pwlab_in] PDL did read msg: code = 0

[pdl :PDL :DBUG/0:     pwlab_in] READ operation completed (0 bytes buffered still, 967 before)

What happens if the second half of the message arrives late? Does the pdl driver throw the “no-match” error? Our network can get extremely congested and 15 seconds might not be long enough.

Also, a while back someone posted a replacement for mlp_tcp.pdl that dumps the buffer if a “no-match” error occurs. Anyone willing to share that code?

Cloverleaf 5.3 Rev2 on Windows 2000

Thanks,

David

[David Garcia]

Please disregard my request for the “no-match” mlp_tcp.pdl. It’s already posted here in the Tcl library section.

David

[Rick Brown]

David,

It sounds like your PDL is timing out.

[Author]

Replies