In some cases the TEPS navigator will hang on the “more” nodes, I haven’t bothered trying to run down the how and why, I just want to see all child-nodes when I select a parent-node.

Here’s how you do it…

Add the following lines to the teps.jnlpt, then rebuild the teps.jnlp

<property name=”cnp.http.url.host” value=”$HOST$”/>
<property name=”cnp.navigator.branch.pagesize” value=”1000″/>
<property name=”cnp.navigator.branch.threshold” value=”500″/>

I was experimenting with WAMP on my laptop, not a big deal in itself, but when I rebooted the Apache server failed to start.

Event logs showed something else had already been binded to port 80.

Quick Fix was to determine which PID had it by running the following:
netstat -ano
From there you can use task manager, determine the conflicting process, kill the PID.

(If you had CYGWIN installed)
netstat -ano | grep :80
ps -Wef | grep <pid> # To determine the process
kill -9 <pid>

Reference: http://help.mosso.com/article.php?id=180

Your script is calling for the “REMOTE_ADDR” and receives the IP of a server in front of one of our back-end servers. The web facing server is then passing the scripts output without giving the expected REMOTE_ADDR of the visitor. In order for your scripts to recognize that they are on a cluster and log the correct IP of your visitors, you will need to replace and add the code below.

For PHP:
Locate any lines of code that are similar to this snippet of code,
$_SERVER['REMOTE_ADDR'];
And replace it with this snippet of code,
$_SERVER['HTTP_X_CLUSTER_CLIENT_IP'];

For ASP:
Locate any lines of code that are similar to this snipper of code,
Request.ServerVariables(“REMOTE_ADDR”)
And replace it with this snipper of code,
Request.ServerVariables(“HTTP_X_CLUSTER_CLIENT_IP”)

My fix for this required a unix shell (if you’re on a Windows look at installing cygwin on your system.

# Ftp your web content down to your local system

$ for file in `find <path_to_files> -exec grep -l REMOTE_ADDR {} \;`; do base=`basename $file`; sed ‘s/REMOTE_ADDR/HTTP_X_CLUSTER_CLIENT_IP/g’ $file > /tmp/$base; grep HTTP_X_CLUSTER_CLIENT_IP /tmp/$base >/dev/null 2>&1 && grep REMOTE_ADDR $file && echo “Updated $base” && mv
/tmp/$base $file; done

# Then simply upload the changed files to your system.

Sympton: TEMS process dies.

Getting “Verify of <table> failed” in ms logs.

Possible EIB Table corruption.

root@someserver:/tmp> /opt/IBM/ITM/ls3263/ms/bin/kgldbutl < qa1cstsc.def

root@someserver:/tmp>

root@someserver:/tmp> /opt/IBM/ITM/ls3263/ms/bin/kgldbutl < qa1cstsc.def

Enter DataBase Utility Command

Enter DataBase Utility Command

DataBase file QA1CSTSC created

Enter DataBase Utility Command

Index PrimaryIndex,U for database QA1CSTSC created

Enter DataBase Utility Command

Instead of copying a large tar file over ssh then extracting, take care of the whole process with one command:

PUSH METHOD:

cat  tarfile | ssh –C user@remotehost “(cd targetdirectory && tar –xf -)”

This will stream the tarfile over a compressed ssl tunnel and the other side will only extract if the target directory exists. The “cd targetdirectory” piece I used as a good prevention to blowing files all over an undesired/unexpected location.

PULL METHOD:

ssh -C user@remotehost”cd sourcedirectory; tar -cvf – dir_or_file” > outputfile

This is the opposite method, obviously.  Please note, the output of the SSH needs to be redirected to an output file.