Forum Replies Created
-
AuthorReplies
-
Just got a response. We are currently on 2022.09.01 and was told to upgrade to latest version in which this “issue” is fixed. So we’re good now.
After upgrading to 2022.09 we’re getting the same thing:
[0.0.175920684] Delivery to destination thread patient_matching failed. Requeuing msg. iclErr=14
Is this a new ‘normal’? As far as we can tell everything seems to be working.
In v2022.09 if you set up a fileset-local thread to a server you lose the \\. Example:
Directories: {\\server\fileLocation} becomes {\server\fileLocation}
If you put in {\\\\server\fileLocation} the verifications clear, but after you close the NetConfig and come back in you get: {\\server\fileLocation}. Then… If you make a change to another thread and come back in your directory is now {\server\fileLocation} and the Verifications tab is complaining.
Anyone else seen this? Any work around? I even tried editing the NetConfig manually, but no dice.
Thank you Charlie. I tested it and it works. I really appreciate your help with this!
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!
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.
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:21The ack is unencapsulated. What would that look like?
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:\\xbI ended up putting in a pre-proc to pull the information. Like Tipu wrote, the element has to be an array. I don’t control the format so… It would be nice if you could iterate on an object and pull the json element values. The example didn’t show it, but what I was dealing with were AOE questions. So it would be nice to get the AOE and answer without having to hard code the AOE. Anyway, thanks for the responses!
Jeff
Can we just go back to the old Clovertech site? No emails, no content, this is worthless…
This forum is what set Cloverleaf apart, please fix Clovertech!
We’re on 7.4 with no issues.
September 21, 2018 at 11:09 am in reply to: Unable to get count of number of messages in smatDB in 6.2 #86503I ran into the same issue. Here is my work-around. If you are using the default database, sqlite, you can do the following from the command line in linux. Go to the directory where your smat file is and do the following:
SmatHistory$ sqlite tcpresults_data.20180920234713.smatdb ‘select count(1) from smat_msgs’
5000
If you cycle the smat files daily and want a monthly count, you can do this:
for i in {01..31}; do sqlite tcpresults_data.201808$i*.smatdb ‘select count(1) from smat_msgs’; done
You’ll get a line for each day.
Hope this helps,
Jeff
Do a search of the documentation for DRIVERCTL. Obviously this depends on the context of the use, but for example what you’ll find under fileset ftp that can be set:
Hey Lonnie, how’s it going? I didn’t see any issues with the recovery database.
-
AuthorReplies