PDL Question

[Jeff Anderson]

I have a system that when I send and ACK to it returns a \x06 which is a tcp ack. My PDL does not recognize it and throughs the following warning/errors:

[pdl :PDL :WARN/   match phrase ack-msg rejected
[pdl :PDL :ERR /0:   no-match: no more phrases to try

Is there a way to capture just the single  \x06 and throw it away?

Any help would be much appreciated.

Topic

[Jim Kosloskey]

It has been a while since I messed with PDL but I seem to remember you can specify multiple phrases inside the pdl (make a copy first) and specify those phrases as acceptable in receipt of message. Then you would need an IB Tps proc to kill messages with just <ack>.

I think the mlp2 PDL has an example of multiple phrases.

Of course, it has been so long, I could be completely off base.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Jeff Anderson]

Thanks Jim

I did already try that with mlp2 taking out the <vt>…<fs>;<cr>;
However it doesn’t catch my <ack>. Like you, I haven’t messed with PDL’s in years and probably only did 2-3 of them to begin with.

 

define phrase basic-msg;
<vt>;
field data = variable-array( not( <fs> ) );
<fs>; <cr>;
end phrase;

/* Each message we write/read must be defined as a phrase.
* Define ACK and NAK.
*/

define phrase ack-msg;
<ack>;
end phrase;

define phrase nak-msg;
<nak>;
end phrase;

hci_pd_msg_style acknak phrase:basic-msg \
field:data \
ackphrase:ack-msg \
nakphrase:nak-msg \
timeout:1000 \
naktries:3 \
tmotries:3 \
resync:\\xb

[Jim Kosloskey]

Well is the ack encapsulated between a vt  and a fs cr as your basic message indicates?

Or does the ack come un-encapsulated?

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Jeff Anderson]

The ack is unencapsulated. What would that look like?

[Jim Kosloskey]

In hex – 0B061C0D.

Since it is not encapsulated I really think what you are experiencing is a mistake on their part. Normally, a system does not application level ack an acknowledgment.

I am not sure you can have multiple basic phrases in a PDL which I think you might need in your case. Perhaps others with more PDL knowledge/experience can chime in.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Charlie Bursell]

Curious here.  What encapsulation are you using with the message that you send to this interface?  I assume is is the MLP protocol.  They must receive it OK else why would they send the Hex 06?  Are they changing their protocol after receipt?  That does make a lot of sense.

Check to see if you actually receive the ACK.  Out and echo statement in a simple reply proc.

Seems to me you need to have a talk with these people.

If the ACK is not important and they never send a NAK you could ignore it by turning off Await ACK  and setting up the interface as send only.   I would hope, in that case, you are not sending faster than the recipient can receive.

[Jeff Anderson]

What happens is I get a result message and send back the ACK. After that the system sends back the 06. I’m’ pasting a more representative sample of the log below. But when I get the 06 back, that’s when I get the match phrase rejected. I’m using the mlp_tcp.pdl currently and have been playing around with the mlp2_tcp.pdl trying to get rid of the error message. Below is the log using enable_pdl (pdl * * *).

 

Engine idle — 03/13/2023 11:11:31

[pdl :read:DBUG/2:horizon_in_v13:03/13/2023 11:14:10] Events: E 0, R 8, W 0
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] read 1511 bytes
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] input buffer accepted 1511 bytes, now 1511
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 0b 4d 53 48 7c 5e 7e 5c |.MSH|^~\|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 26 7c 48 4f 52 49 5a 4f |&|HORIZO|
PHI Message Removed
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 30 30 5e 53 5e 46 7c 46 |00^S^F|F|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 52 49 44 54 0d 1c 0d |RIDT…|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] IDLE and 1511 bytes but no error: starting READ
[pdl :PDL :DBUG/2:horizon_in_v13:03/13/2023 11:14:10] PDL changed states: old 0, new 1
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] Calling Tcl procedure: hci_pd.read
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] with args: {}
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] Tcl procedure hci_pd.read returns ‘RECEIVE’
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] trying to match phrase: basic-msg
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] multi_phrase_2: status = ok
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] Calling Tcl procedure: read.done
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] with args: {{status ok} {end {1511 0}} {data {1 1508}}}
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] Tcl procedure read.done returns ”
[pdl :PDL :DBUG/2:horizon_in_v13:03/13/2023 11:14:10] PDL changed states: old 1, new 0
[pdl :read:DBUG/1:horizon_in_v13:03/13/2023 11:14:10] PDL did read msg: code = 0
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] READ operation completed (0 bytes buffered still, 1511 before)
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] bound message 0000003EF1A0D860 to `message0′
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] (message length is 125)
[pdl :PDL :DBUG/2:horizon_in_v13:03/13/2023 11:14:10] PDL changed states: old 0, new 2
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] Calling Tcl procedure: hci_pd.write
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] with args: {{message message0}}
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] Tcl procedure hci_pd.write returns ‘TRANSMIT’
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] writing out 128 bytes:
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 0b 4d 53 48 7c 5e 7e 5c |.MSH|^~\|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 26 7c 43 4c 4f 56 45 52 |&|CLOVER|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 4c 45 41 46 7c 33 30 37 |LEAF|307|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 35 32 5e 57 47 4e 7c 48 |52^WGN|H|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 4f 52 49 5a 4f 4e 7c 41 |ORIZON|A|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 65 67 69 73 20 53 63 69 |egis Sci|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 65 6e 63 65 73 20 43 6f |ences Co|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 72 70 6f 72 61 74 69 6f |rporatio|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 6e 5e 34 34 44 32 30 36 |n^44D206|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 32 33 33 33 7c 32 30 32 |2333|202|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 33 30 33 31 33 31 31 31 |30313111|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 34 31 30 7c 7c 41 43 4b |410||ACK|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 7c 37 30 35 32 30 38 7c ||705208||
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 50 7c 32 2e 35 2e 31 0d |P|2.5.1.|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 4d 53 41 7c 41 41 7c 37 |MSA|AA|7|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] 30 35 32 30 38 0d 1c 0d |05208…|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] write buffer has 128 bytes, currently at +0
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] wrote 128 bytes out of 128
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] write buffer has 128 bytes, currently at +128
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] Calling Tcl procedure: write.done
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] with args: {{status ok}}
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:10] Tcl procedure write.done returns ”
[pdl :PDL :DBUG/2:horizon_in_v13:03/13/2023 11:14:10] PDL changed states: old 2, new 0
[pdl :wrte:DBUG/1:horizon_in_v13:03/13/2023 11:14:10] PDL did write msg: code = 0
[pdl :read:DBUG/2:horizon_in_v13:03/13/2023 11:14:11] Events: E 0, R 8, W 0
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] read 1 bytes
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] input buffer accepted 1 bytes, now 1
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] 06 |.|
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] IDLE and 1 bytes but no error: starting READ
[pdl :PDL :DBUG/2:horizon_in_v13:03/13/2023 11:14:11] PDL changed states: old 0, new 1
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] Calling Tcl procedure: hci_pd.read
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] with args: {}
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] Tcl procedure hci_pd.read returns ‘RECEIVE’
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] trying to match phrase: basic-msg
[pdl :PDL :WARN/0:horizon_in_v13:03/13/2023 11:14:11] match phrase basic-msg rejected
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] multi: phrase #0 rejected; trying next
[pdl :PDL :ERR /0:horizon_in_v13:03/13/2023 11:14:11] no-match: no more phrases to try
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] Calling Tcl procedure: read.error
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] with args: {{status error} {type no-match}}
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] pdiIgnoreInput: chop to 1, bolen 0
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] pdiIgnoreInput: after clear: 0 + 0
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] pdiIgnoreInput: chop to 4294967295, bolen 0
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] pdiIgnoreInput: after clear: 0 + 0
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] Tcl procedure read.error returns ‘0’
[pdl :PDL :DBUG/2:horizon_in_v13:03/13/2023 11:14:11] PDL changed states: old 1, new 0
[pdl :PDL :DBUG/0:horizon_in_v13:03/13/2023 11:14:11] READ operation completed (0 bytes buffered still, 1 before)
Engine idle — 03/13/2023 11:14:21

[Charlie Bursell]

So you are getting an ACK to an ACK?  Strange.

You can certainly modify the mlp_tcl.pdl to ignore that.  But then you would have a non-standard PDL  We could copy the mlp_tcl.pdl file and modify that and then rename.  But again, no standard and confusing to those that may come after you.

Are you sure you want to do that?  It would be best if you could talk with the vendor and tell him to stop it. Another alternative, of course, would be to just ignore the message in the log file. It does not seem to affect your message flow.

[Jeff Anderson]

I’d like to make a copy of the mlp_tcl.pdl and set it up to ignore the second ACK, but I don’t know how to do that. Any help with that would be greatly appreciated.

[Charlie Bursell]

I’ll give a try.  Should the ACK be simply dismissed or returned to thread?
I would assume just dismiss as you would have to handle the ACK if returned to the thread.

Also assume they only send ACK and not NAK.  If they send a NAK you would still get a no-match error.  That would be a good thing so you would know.

Let me know.

 

[Jeff Anderson]

The ACK should simply be dismissed and not returned to the thread. I have not seen a NAK so I agree it would be good to see the no-match error for that. I really appreciate your help with this!

[Charlie Bursell]

Not going as good as I hoped.  Seems PDL does not like multiple phrases with different encapsulation.  I can get rid of the <ACK> and subsequent no-match error but then get another message in the log like:
conn_3:03/21/2023 11:40:43] match phrase basic-msg rejected

Not sure we want to trade the no-match message for this one.

I am obstinate enough to keep trying at least for a while.  🙂

Jeff:

Send me an email at cbursell@fastem.com so if more question we can communicate there.

 

[Charlie Bursell]

I have sent the modified PDL to Jeff.  I thought I would post it here in case there is any interest of a typical modification.

Note I put a .txt suffix on so it would upload.  The suffix should be .pdl

Attachments:

You must be logged in to view attached files.

[Jeff Anderson]

Thank you Charlie. I tested it and it works. I really appreciate your help with this!

[Author]

Replies