[Hyunyoung Park]

I’m experiencing the exactly same issue as Dale posted above. Same sequence of activities as he described crashes the process and gives the same error comments. PANIC: assertion ‘0’ failed at PthreadInterface.cpp/719

Does anyone have an idea what is causing the panic?

[Hyunyoung Park]

David, yes you are right, the client key that Cloverleaf is presenting. I probably used an incorrect term since I don’t have much knowledge about SFTP configuration.  🙂

We didn’t make any change in Cloverleaf. SFTP server side updated their key to match the current cloverleaf box key.

There are 2 sftp servers that Cloverleaf interacts. One server ever gives us no problem but this new Sterling server which I have referred as SFTP server so far seems to have somewhat restrictions and limitations.

Thank you everyone for your inputs! I’ll discuss more with our AIX group and SFTP group.

[Hyunyoung Park]

No, SFTP server is a different server from cloverleaf box.

Cloverleaf is on clustered env and we did failover Cloverleaf.

SFTP server had the SSH host key of the cloverleaf active node at the time they initially configured the connection with us. After we failed over the cloverleaf box, now the host key of the cloverleaf box doesn’t match with the one SFTP server knows.

For now, SFTP updated SSH host key to our current active node’s but this issue will occur when we failover next time again.

[Hyunyoung Park]

You can probably use 2 flag variables. One for positive and the other for negative. After each table look-up, if return is N, set negative flag to 1 and if return is P, set positive flag to 1.

After the loop, evaluate both variables and kill the message only when Positive flag = 0 AND negative = 1.

[Hyunyoung Park]

I had the sending system fix the issue and it resolved. Thank you David and Jim.

[Hyunyoung Park]

Thank you Rick.

After seeing your post, I carefully checked variant files again and two files had different modified dates. Copied them to Test and worked!!

[Hyunyoung Park]

Thanks for the replies but I’m still in trouble..

I have very limited knwoledge about gdbm.

Is there a way to close an open db (a sort of reset function)?

All the messages in the threads that access gdbm are piling up in error db and the number is going up like crazy.. Please help!

[Hyunyoung Park]

It has open and close syntax….

---

  gdbm_open $db_name

  set rc_cd [catch {set int_acc_num [lindex [split [gdbm_fetch $db_name $key_val] ” “] 0]} err]

  if {$rc_cd} {

     echo ERROR_MESSAGE:$err

     set int_acc_num “NOT_FOUND”

  }

  gdbm_close $db_name

  set xlateOutVals $int_acc_num

[Hyunyoung Park]

Thanks Dan,

When I had a quovadx support on the phone, he told me that he has seen only two reasons causing 924 error. One is running back-up job during busy hours can cause crash and the other is when a thread/process name has uppercase in it. But neither of them was our case and he couldn’t pinpoint what caused it on our case. Making unique process names throughout all sites was his recommendation.

According to you Dan, the length of process/thread name can be issue..I just counted our thread names and several of them are 14 – 17 characters long and these names have been always same throughout different versions of cloverleaf (currently we are on 5.4) and I think I have seen this 924 error two times so far only after we migrated to 5.4 and none before.

There is no specification from Quovadx about these recommendations, and so forth and I’m wondering how much their recommendations are truly affecting.

[Hyunyoung Park]

Thank you for your kind response!!

I’ll try the scripts that you provided.

Thanks,

Jennifer

[Hyunyoung Park]

It works!! Thanks!!!

[Author]

Replies