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

[Max Drown (Infor)]

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)

Topic

[Max Drown (Infor)]

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)

[Nate Kruse]

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.

[James Cobane]

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

[Max Drown (Infor)]

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)

[James Cobane]

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

[Max Drown (Infor)]

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)

[Bob Richardson]

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