[Calvin Palmer]

Steve, Was there ever an answer for this issue?

[Calvin Palmer]

Congratulations are in order,

Enjoy your retirement, Charlie (Chuck B). It has truly been an enriching experience to have had you in the Cloverleaf community. Your legacy and contributions to the community will live on.

[Calvin Palmer]

Jim,

I’ve always been taught that 4000 is THE MAX and cannot be exceeded. Not sure if this helps… 🙁

[Calvin Palmer]

GM 5.0 will find all SMAT that is under $HCIROOT but be careful. GM creates “smatindexes” that can grow pretty large depending on the amount of SMAT you have on your server. These indexes aid the speedy search of the actual SMAT files. GM will not clean up the SMAT indexes that are found outside of the site directories. That is to say that if you move/delete SMAT files from those “outside” directories, the index files that are created by GM will need to be manually deleted. This cleanup can be automated by creating scripts to sync up those directories.

Hope that helps.

[Calvin Palmer]

Hey guys,

Don’t forget you have to bounce the thread in question to get those messages out of memory after you’ve deleted them out of the database. I would keep the -U so that you don’t “tie up” the default database user.

[Calvin Palmer]

This turned out to be a problem with the variant that the translation was using. A Z-segment had been added without any field definition. Not sure how. The user may have lost his/her session while editing the variant.

[Calvin Palmer]

Hey Rehman,

Looks like S12,13,15,and 26 will go to _sch (not S14). You could use the wildcard route ^S1[2|3|5].*,^S26.*

What you have should work as long as there are no errors in your translation objects which could cause a route to get missed.

[Calvin Palmer]

An error in a translation object can also cause the translate thread to stop populating the partial queues for those routes that have not yet been processed. I would check the tranlsation and TCl procs for the new thread.

[Calvin Palmer]

I’ve received word that R and D is looking into the issue. I’m also told to expect a fix to be issued in a rev level release. No time frame was given. Meanwhile we plan to go live on 5.8.3 P this weekend with all of our IP connections re-configured to use the PDL instead of encapsulation.

[Calvin Palmer]

I saw your post concerning the connectivity issues, Mike. I notice that you’re on Red Hat. We’re on AIX 6.1 and run into that connection issue using the PDL on outbound connections to several different remote servers and not just inter-site connections. I don’t know if the difference in what we’re seeing lies in the fact that we are using a different O/S than you.

I hope to hear from my favorite support guru at Lawson today on what he sees. I’ll keep you all informed.

[Calvin Palmer]

Jim, Yes I’ve opened a case and am awaiting a reply. The main issue that we see if we use PDLs has been mentioned on CLTech earlier. The TCP/IP host has to be up before any CLoverleaf outbound clients attempt to connect or the connection never happens.

[Calvin Palmer]

Oops! Thanks for the correction! 🙂

Rich Durkee wrote:

In Calvin’s reply he stated to use this command:

hcicmd -dd threadname

He meant to say:

hcimsiutil -dd threadname

Rich Durkee

[Calvin Palmer]

Simply type hcimsiutil -dd [threadname] without the brackets. This will return statistical information about the thread in question including queue info.

[Calvin Palmer]

Julie,

You also want to make sure that the segments that you expect to be copied appear in matching groups and occurences for the message in question.

[Calvin Palmer]

Environment: Cloverleaf 5.3 on AIX 5.2.

We are using SSL encryption to connect via VPN to a vendor using a TCP/IP sockets connection. It’s been rock solid for a few years now. I used a third party SSL package to generate my keys, got the SSL license from Quovadx, then configured the thread with the location of the license key files and voila!

[Author]

Replies