I found that installing Oracle on Linux and CentOS for that matter was not a straightforward process but for that matter there were also some issues in hooking VisualWorks up that made for a bumpy ride. Any senior Smalltalker / developer probably would eventually figure things out but in the hopes of saving others some of the pain I went through I’ll detail my little adventure below.

Oracle Installation

Once upon a time in a land not so far away I found myself in front of a Linux box with an Oracle 10 g client install CD. My objective was to install Oracle 10g Instant client i.e. that which simply installs the libraries required for the Oracle client call interface and nothing more, nothing less.

Problem: CentOS is not recognised as “supported” Linux distro.

and here is where I forget what I did. Have to write these blog entries closer to time zero. Essentially, the “runInstaller.sh” found at the top of the Oracle Client 10g CD can be run with a flag which means don’t check if the current OS is a valid distro etc. I’ll try to dig up that flag and amend this article but I do recall that in particular the CentOS forums where helpful.

Configuring VisualWorks

It is extremely important to provide visibility for the Oracle libs from the get go. This is accomplished by setting two environment vars to the location of the Oracle libs. This was done in the startup script for my VisualWorks image. The entries are:

ORACLE_HOME=/apps/oracle
export ORACLE_HOME

PATH=$PATH:$ORACLE_HOME/lib
export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib
export LD_LIBRARY_PATH

Note that the Oracle documentation states that env var “ORACLE_HOME” does not need to be setup for the call interface to work. Also the install of Instant client does not create a “lib” directory. I created one because the directory structure the installer creates is just too painful for me. So I simply took the libraries and put them in the lib directory which I created under ORACLE_HOME.

Configuring Oracle

Oracle call interface will require the following env vars to be set as follows:

NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
export NLS_LANG
TNS_ADMIN=$ORACLE_HOME/lib
export TNS_ADMIN

NLS_LANG is I assume pretty self explanatory but TNS_ADMIN is not. As a matter of fact, nobody knew in this shop what that did. The reason being is that when one performs any of the “fatter” install options this var is set underneath the covers. TNS_ADMIN specifies the location where the tnsnames.ora file resides. Entries in this file follow the pattern illustrated below:

TBOPROD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = linux)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = tbOPROD)
)
)

etc …

So let’s break this down:

• TBOPROD = this is simply the label assigned to the entry above.
• Host & Port = host and port where the oracle cluster is running.
• SERVICE_NAME = the name of the database instance.

Your dba usually sets this file up and usually generated by Oracle configuration tools.

Calling Oracle

The following workspace code illustrates how to retrieve a connection:

connection := OracleLinuxInterface new.
connection username: ‘Charles’
connection environment: ‘//MyLinuxBox/TBOPROD’.
connection connect: ‘smalltalkrocks’

It had been probably about 1.5 years since I last tried to use Postgres on Windows as a backend for StORE, the source code versioning environment for VisualWorks. It was not happening at all. At that time I decided to use the Interbase/Firebird backend because it was a multi-user solution which was stable and that was a step up from what I had been using at the time namely Access. Why is a multi-user backend necessary? Well, because it one wants to collaborate with somebody there is no to setup some centralized repository somewhere you can do it peer to peer which sure beats passing parcels around. However the Interbase/Firebird solution was not quite perfect. So now I have decided to move on to using Postgres on Windows as my StORE backend the reasons being:

• Good security which means that participants do not have to be confined to the same local network
• Very easy install on Windows
• the admin tools are good, making it easy to setup users and multiple databases
• Postgres works with Glorp and thereofore with the Glorp Store replicator
• I want to start working with something that uses Glorp since we plan to use it in the near future
• Finally, this is the setup that many of the Cincom Smalltalkers seem to be using i.e. from my talks at SS 2005

I don’t have much spare time to spend on non-compensated Smalltalk work. Sure, I enjoy coding with Smalltalk but nowadays I have returned to my original passion which is playing the guitar. My quota is a minimum 10.5 hours of guitar per week although it is difficult to consistently achieve that. Then there is walking the dog for at least an hour per day if not more. I am also married , need I say more. So I choose my pet Smalltalk projects very carefully. I have a few active ideas. However, when I found at that Terry Raymond had built a core Traits engine that was just too much to resist. Why?

• I believe Traits has the potential to be quite useful.
• I knew Terry would have something substantial that I could sink my teeth into.
• I did not have a presenter scheduled for the NYCST March meeting. That usually means that I have to try to put something together quick.
• I have been feeling guilty about not contributing to the community with product and this seemed like a great chance.

So sometime in February I decided that I was going to do my best to add StORE and RefactoringBrowser integration to VW Traits and to present the work at the March meeting for NYC Smalltalk. It was close but that is what I did.

The presentation I thought went well. Terry Raymond which lives about 4 hours away up in New England decided to come and visit us which was a definite plus. The discussions at the meeting and then later at the bar went great. I think we gathered some nice ideas on how to extend Traits and make it even more powerful.

I won’t bore you all with any further detail. Those so inclined can start by checking out the Traits section on our wiki.

Finally, I have published the work to the Cincom Public Repository. Load bundle: ‘VW Traits Development 3’.

I would be very much interested in feedback as I am sure so would Terry Raymond.

One very easy way of sending text messages from a VisualWorks application is to simply send email to a provider that forwards the email to your cell phone. See my previous blog for an example of SMTP in VW.

One such provider is Verizon Wireless. Email sent to yourPhoneNumber@vtext.com will get forwarded. Messages are truncated to 250 characters and attachments are of course ignored. I figured that most cell phone providers would have similar service but from a quick look it seems that most have web interfaces but not many an email interface. However, there are companies out there that offer the service. One such company is www.ipipi.com. What is interesting about them is that email will be forwarded to your cell phone depending on rules that are setup.

We plan to shortly be able to alert our users of production issues via text messaging by leveraging SMTP in VisualWorks.

The other day I decided to play with the idea of facilitating the notification of issues back to us. Our users are off-site.. So I decided to hook up to the SMTP capabilities of VW. As a proof of concept, I decided to modify the Notifier so that instead of providing a “copy stack” button it provides a “Send Stack” button. This is pretty easy to do by simply overriding:

DebuggerService>>>
openDebugger: aDebugger contents: aString1 label: aString2 proceed: mayProceed displayAt: aPoint

it will be quite apparent where to make the mods.

I then use MailMessage to send an email to my work account as well as to my cell phone. It is a simple as this:

| message smtpClient |
message := MailMessage newTextPlain.
message from: 'santa@northpole.net';
to: 'timmy@yourmail.net';
subject: 'Start making your list now';
text: 'What would you like for Christmas?'.
smtpClient := SimpleSMTPClient host: 'smtp.northpole.net'.
smtpClient sendMessage: message.

The above is straight from the VisualWork’s documentation. Messages can also carry attachments. For more info check out the NetClientDevGuide.pdf which comes with the VisualWorks Cincom distribution.

The overriding need is not for bugs per se but rather for production events such as abnormal termination of batch jobs etc. My plan is to make the application much more aware and responsive of runtime issues. Partly by perhaps incorporating VW’s SNMP framework but also by simply more carefully tracking runtime events in the daily business cycle.

SMTP seems like a reasonable viable possibility. Mail messages can of course be sent programatically. The question is whether the users will feel this to be a security risk. We should be able to encrypt mail. Well, we shall see how this turns out.