Finding the OCS server on your network

Had to find the OCS server to configure MOC client.
The steps below helped me to do so:

1. open nslookup
2. set q=SRV
3. _sipinternaltls._tcp.[domain fqdn]
Above command should return IP and port (by default 5061) to your pool.
4. _sipinternal._tcp.[domain fqdn]
Above command should return IP and port (by default 5060) to your pool.

Finding Oracle DB Version

How do you find the Oracle DB version using SQL query?
Connect to the Oracle DB and run following SQL Query:

select * from v$version

Typical output:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
"CORE 10.2.0.4.0 Production"
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

File Encodings, Character sets and JVM

I wanted to determine the type of file and its encoding (ASCII/Unicode) etc.
Found this link helpful: http://www.cyberciti.biz/faq/linuxunix-determine-file-type/

Further I also wanted to check the default character set supported by the Solaris system and used by the JVM at run-time. The primary reason behind checking this was the unusual behavior of the Java function RandomAccessFile.writeChars.

From the Javadocs, writeChars is always supposed to write characters as a two-byte value. But I observed that on one system it generated an ASCII file while on another it generated a Unicode file. Since I wanted to generate an ASCII file, I switched to using writeBytes.

But the mystery below is unsolved and is for a later date:
On Solaris box A (SunOS 5.10): RandomAccessFile.writeChars was writing ASCII characters
On Solaris box B (SunOS 5.9): RandomAccessFile.writeChars was writing UNICODE characters

I used the program here as a reference for finding the default system character set.
Solaris Box A (using JDK 1.6 Update 11) provided the output:
Default Charset=ISO-8859-1
file.encoding=ISO8859-1
Default Charset=ISO-8859-1
Default Charset in Use=ISO8859_1

Solaris Box B (using JDK 1.6 Update 26) provided the output:
Default Charset=US-ASCII
file.encoding=ISO646-US
Default Charset=US-ASCII
Default Charset in Use=ASCII

Understandiing ADAM

Adam was the first person on earth. But this ADAM is different :). As it is one of the last LDAP Directory Servers to enter into the family of directory servers known to the world.

It refers Active Directory Application Mode - which is Microsoft's answer to enterprises
who want the 'power' (I know some people will put a question mark on this) of AD along with the flexibility offered by popular application directory servers like Sun ONE.

For more details of ADAM check the TechNet website.

Storing standard output in AWK program variable

Within my awk script, I had to perform a search and capture the results of the search operation within a program variable for further processing.

To perform the search - grep was used and it was invoked within awk using the system function. The hurdle was to assign the result of the operation to a program variable in awk.
The system function returns an error code, so a direct assignment was ruled out. The workaround (or may be the right solution) is to make use of the getline function.

The code snippet is given below

cmd = 'grep "LDAP:" applnList.txt > tmpfile' ;
system(cmd) ;
getline expectedLine < "tmpfile" ;

Persistent Search Control

Very often application developers fetch data from backend systems and store them in application-specific cache memory to speed up response times and enhance user experience. While doing so, they also need to take care of refreshing the data in cache and making sure that the user is not presented with stale data. Maintaining stale data in the cache can potentially impact business critical applications.

It is very commendable that LDAP protocol designers have taken cognizance of this issue and have proposed implementation Persistent Search Control - a mechanism that allows server to notify 'caching' clients of changes in LDAP data. The Novell site provides good tech notes (http://support.novell.com/techcenter/articles/dnd20030204.html) on Persistent Search Control.

Today, most LDAP servers support the Persistent Search Control extension and there are many applications which leverage this control to update cached data.

One such application is the Sun Access Manager which extensively leverages LDAP to provide Access Management functionality to business critical applications.

Sun Access Manager 2005Q1 makes use of Persistent Search Control mechanism to refetch data from the Sun Directory Server. Since the Persistent Search Control mechanism is transparent in its operation, usually the Access Manager administrator is not even aware of this 'hidden' communication between Access Manager and the Directory Server.

There is a separate EventService thread in Access Manager that takes responsibility for Persistent Search operations. You will find the activities of this thread logged in the debug file amEventService. The designers of EventService have also taken care to provide a property com.sun.am.event.connection.idle.timeout to enable restart of Persistent Search operations in case of lost connections. It is especially important to configure this attribute in case Access Manager is communicating with load-balanced Directory Servers. Set this attribute to a value lower than the load-balancer time-out.

How load-balancers implement session persistence?

Load balancers implement session persistence using two mechanisms -

• Cookie Based Hashing
• Cookie Based Switching

The documentation provided by Foundry Networks gives a nice explanation of these two techniques.