REPLYGEN specified to use ‘procs’, but no procs defined

This topic has 7 replies, 4 voices, and was last updated 16 years, 8 months ago by Bob Richardson.

Creator

Topic
April 7, 2008 at 8:11 pm #49959
Max Drown (Infor)
Keymaster
Another … oddity .. while regression testing 5.6.

I changed the outbound thread from pdl-tclip to file and unchecked “Await Replies”. Then I bounced the process, cleaned out all of the data, etc. I then resent the test messages using hcicmd.

Code: [cmd :cmd :INFO/0: bn11_cmd:04/07/2008 15:02:49] Received command: ‘bn11phs_out pstart’ [cmd :cmd :INFO/0: bn11_cmd:04/07/2008 15:02:49] Doing ‘pstart’ command on ‘bn11phs_out’ [pd :thrd:WARN/0: bn11phs_out:04/07/2008 15:02:50] REPLYGEN specified to use ‘procs’, but no procs defined

Code: 1 14-OB delivered bn11ms4_in bn11phs_out 3186 11-OB post-SMS bn11ms4_in bn11phs_out

I can’t find ANYWHERE in the outbound thread where I have anything tcp/ip related configured. Why do I have a state 14 message and why the REPLYGEN error in the log?

-- Max Drown (Infor)
Creator

Topic

Viewing 6 reply threads

Author

Replies
- April 7, 2008 at 8:15 pm #64254
  Max Drown (Infor)
  Keymaster
  Some further research shows …
  
  The NetConfig has “Await Replies” unchecked. The fields are greyed out, but you can still see hcitpsmsgkill in the “TPS Inbound Reply” field even tho the field is greyed out. I’ve attached a screenshot.
  
  Examing the NetConfig from the command line returns this …
  
  Code: THREAD: bn11phs_out Process: bn11 Protocol: file Infile: /dev/null format: nl Outfile: /dev/null Trx ID determination: frl IB Reply Procs: hcitpsmsgkill Args: {} Reply Gen Proc: Routes:
  
  Apparently, Cloverleaf is still aware of hcitpsmsgkill.
  
  -- Max Drown (Infor)
- April 8, 2008 at 1:03 pm #64255
  Nate Kruse
  Participant
  In 5.5rev1, we also have fields that are unchecked and disabled, but still hold values…such as smat file paths and Inbound Replies on the outbound tab. I don’t think we have seen any issue with it, but I find it a bit sloppy (possibly confusing) that when a parent field is changed that the children are not reset to blank.
- April 8, 2008 at 2:09 pm #64256
  James Cobane
  Participant
  As far as I recall, it’s always been this way. Personally, I like the fact that it keeps the information there, but ‘disables’ it. It makes it convenient when you are temporarily changing the configuration for testing (i.e. changing the protocol to ‘file’ and turning-off ‘Await Replies’); it’s one less thing to remember (which procs were there) when you flip it back on.
  
  Jim Cobane
  
  Henry Ford Health
- April 8, 2008 at 2:13 pm #64257
  Max Drown (Infor)
  Keymaster
  ~~James Cobane wrote:~~
  
  As far as I recall, it’s always been this way. Personally, I like the fact that it keeps the information there, but ‘disables’ it. It makes it convenient when you are temporarily changing the configuration for testing (i.e. changing the protocol to ‘file’ and turning-off ‘Await Replies’); it’s one less thing to remember (which procs were there) when you flip it back on.
  
  Jim Cobane
  
  Henry Ford Health
  
  I agree that that would be nice, however it appears Cloverleaf is NOT disabling the field (at least not in this case).
  
  -- Max Drown (Infor)
- April 8, 2008 at 3:27 pm #64258
  James Cobane
  Participant
  Max,
  
  We haven’t seen this issue in our 5.6 testing, but the difference may be that our configuration DOES have a replygen proc specified; we didn’t remove it when we unchecked ‘Await Replies’ and changed the protocol to file. See excerpt from NetConfig below:
  
  protocol to_bic_ecin_adt {
  
  { AUTOSTART 1 }
  
  { BITMAP hcilogo }
  
  { COORDS {0 0} }
  
  { DATAFORMAT {
  
  { FRLTYPE offlen }
  
  { OFFLEN {
  
  { LEN 0 }
  
  { OFF 0 }
  
  } }
  
  { TYPE frl }
  
  } }
  
  { DATAXLATE {
  
  ….more config info….
  
  { OUTBOUNDONLY 1 }
  
  { PROCESSNAME bic_ecin_adt }
  
  { PROTOCOL {
  
  { IBCRNLCONVERT 0 }
  
  { INDELAY 0 }
  
  { INFILE /dev/null }
  
  { INFORMAT nl }
  
  { OBCRNLCONVERT 0 }
  
  { OUTAPPEND 0 }
  
  { OUTFILE /dev/null }
  
  { OUTFORMAT nl }
  
  { RECONNECT 0 }
  
  { TYPE file }
  
  } }
  
  { RECVCONTROL {
  
  { ACKCONTROL {
  
  { ARGS {} }
  
  { PROCS {} }
  
  } }
  
  { EOMSG {} }
  
  { MSGPRIO 5120 }
  
  } }
  
  { REPLYCONTROL {
  
  { OBRESEND 0 }
  
  { REPLYGEN {
  
  { PROCS {
  
  { ARGS {{}} }
  
  { PROCS resend_ob_msg }
  
  } }
  
  { TYPE procs }
  
  } }
  
  { TIMEOUT 60 }
  
  { WAIT 0 }
  
  } }
  
  Jim Cobane
  
  Henry Ford Health
- April 8, 2008 at 3:32 pm #64259
  Max Drown (Infor)
  Keymaster
  At first all I did was change the protocol to file and uncheck Await Replies, but I kept getting messages stuck in state 14 during during the regression testing. I had to actually remove hcitpsmsgkill to get the messages to flow through the interface properly.
  
  Check out the log error and database dump I posted above to see what I mean.
  
  There shouldn’t be any state 14 messages when the protocol is file, right?
  
  -- Max Drown (Infor)
- April 9, 2008 at 12:59 pm #64260
  Bob Richardson
  Participant
  Greetings,
  
  Reply/Resend is not restricted to just the traditional TCP/IP configurations.
  
  At times when I need to save messages to a fileset in Production due to the remote side being down (for whatever reason) I forget to turn off the await replies/resend logic which is on the Outbound tab. So a message is saved then the thread hangs as it waits for a reply which will never arrive from the “remote”. You can actually set up full reply/resend between two fileset type threads – it is not restricted.
  
  Other than that, we have been evaluating 5.6 on AIX5.2 and have not found any issues with fields that are disabled but get invoked at run time
  
  due to stuff left in the text boxes.
  
  Hope this helps.
Author

Replies

Viewing 6 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.