Practically Agile
Using Agile in less-than-perfect situations since Y2K
Using Agile in less-than-perfect situations since Y2K
Yesterday, I posted my technique for installing Informix on a Mac. Well, it turns out I wrote just a bit too soon. What I had was indeed working, but only for the “dbaccess” tool that ships with Informix. Trying to connect from a Java (JDBC) application failed.
Thanks to Eric Herber’s comment on that post, the PDF it mentions, and a bit more research, I was able to make a two significant updates to my installation.
Reading through the PDF, it notes that the informix user and group are required in order for things to work properly. Examining my install, it seems that the IDS installer tried to create the informix group, but somehow assigned it the same group ID as the _lpoperator group. I believe _lpoperator is the group of people who can use the Mac’s printers. Regardless, it wasn’t the informix group that it should have been.
Important! If you don’t understand what is meant by user and group here, my best advice would be to get someone who does to help you. I don’t want to insult anyone, but making changes to the things I am about to mention could render your machine unusable. Here be dragons!
To fix this issue, I had to do two things. First, create the informix group and make it the informix user’s “primary” group. Second, I had to change the group ownership of everything in my Informix install directory from _lpoperator to the new informix group. The PDF talks about using the Workgroup Manager that is available in the OS X Server Admin Tools. I will let you read that for the details except to say that the correct URL for acquiring the tools depends on the version of OS X you have. Regardless, the URL in the PDF is outdated, as is one I found in a search on MacOSXHints. The best means I have found is to go to the Apple Support site’s Advanced Search, enter “server admin tools”, select the radio button to match all keywords, use the drop-down to restrict the document type to “Downloads”, and pick the version you want from the results. I am far from certain, but it would make sense to pick the one closest to your version of OS X.
Once you have the Server Admin Tools download, it is a simple, and typical Mac install. Once installed, you can run the Workgroup Manager tool more or less as stated in the PDF. Do not skip the step that asks you to select “Show All Records” from the “View Menu”. This may be “Show System Records” depending on the version of the tool. If you know a little about Unix user management, the tool is fairly intuitive. If you know a lot about Unix user management, you may prefer the command line tools that can do the same thing. Regardless, I simply had to create the informix group and make it the informix user’s primary group.
It is worth noting that if I had created the informix user and group using this tool before running the installer, I probably would not have had the _lpoperator nonsense nor would I have had to do the next step: changing the group ownership of all the files in my Informix install.
To change the group ownership, I went back to the command line and did the following:
$ cd /Applications/IBM/informix $ ls -l total 11656 drwxr-xr-x 3 root staff 102 Aug 15 2008 CSDK drwxr-xr-x 5 root staff 170 Aug 15 2008 DBLD drwxr-xr-x 3 root staff 102 Aug 15 2008 ICONNECT -rw-r--r-- 1 root staff 5904 Aug 14 2008 README.html drwxr-xr-x 7 root staff 238 Aug 15 2008 SERVER drwxrwxr-x 4 informix _lpoperator 136 Jan 13 15:50 aaodir drwxr-xr-x 109 informix _lpoperator 3706 Jan 13 15:54 bin ... -rwxr-xr-x 1 root _lpoperator 29713 Aug 14 2008 uninstallserver $ sudo chgrp -R informix aaodir ...
Note: The “…” on line 11 means there were a lot of other entries. The one at the end means that I repeated that “sudo chgrp” for all of the files and directories that had group ownership of _lpoperator.
That group information was annoying and tedious to fix, but it was not really the problem. If you recall from the earlier post, there are some environment settings that need to be loaded. One points to a file that is very important to enabling clients to connect to the server: INFORMIXSQLHOSTS. The whole purpose of the file is to define the mechanisms by which clients can connect, this means whether they must be using shared memory space or can use sockets and what port they use to connect. The one created by the installer for the demo database has a single line that looks like this:
demo_on onsoctcp yoda.local 9088
The first is the dbservername and is correct for the demo database. The second is a three-part string that identifies how clients can connect. In short, “on” means a regular database server (short for on-line as in OLTP maybe), “soc” means sockets as opposed to “shm” for shared memory, and “tcp” means the network protocol. So, this seems right as well. The other two entries are the machine hostname and the port. However, although my Mac is named “Yoda” (yes, I’m a Star Wars geek), that is not listed in the /etc/hosts file. I changed this to “localhost” which is in the hosts file. Finally, that last entry is meant to be the service name from the /etc/services file, not the port number. To figure out how to change this, I used the following command:
$ cat /etc/services | grep Informix sqlexec 9088/tcp # IBM Informix SQL Interface sqlexec 9088/udp # IBM Informix SQL Interface sqlexec-ssl 9089/tcp # IBM Informix SQL Interface - Encrypted sqlexec-ssl 9089/udp # IBM Informix SQL Interface - Encrypted
My final file still contains one line, which looks like this:
demo_on onsoctcp localhost sqlexec
And now, everything is working smoothly. Whew!
Tags: informix, install, mac, osx, snow leopard
Update: I had some problems connecting to Informix via Java. Also, the process below led to an issue with the “informix” user’s group settings. I have created a “part 2″ post to detail what happened and how I managed to fix it. Please read that before using these instructions to perform your own install.
I have recently started a project with a group that uses Informix as the database. To set up my development environment to match production as closely as possible, I have installed IDS for Mac. The instructions that you can find on the web caused me some difficulty. There is a video available from IBM that would be great, but it seems to be outdated slightly. (Viewing it may still give you some benefit, so you can find it here.) To save myself time in the future if other Mac users need to join the project, I have documented what I believe to be the final process here.
Caveats:
If you try this out and find some things that don’t work or ways to make it faster or easier, please let me know in the comments. I will happily incorporate them.
One quick formatting note, when command examples are given, the “$” at the beginning of a line is in place of the command prompt. By default in the Mac Terminal app, this is usually of the form “hostname:current_directory username$”. If you copy and paste the commands, remove the “$” and the space after it.
kern.sysv.shmmax=4398046511104 kern.sysv.shmmin=1 kern.sysv.shmmni=512 kern.sysv.shmseg=512 kern.sysv.shmall=1073741824 kern.sysv.semume=10 kern.sysv.semmsl=87381 kern.sysv.semmnu=87381 kern.sysv.semmns=87381 kern.sysv.semmni=87381 kern.maxfiles=2147483647 kern.maxfilesperproc=40000 kern.maxvnodes=150000
$ sysctl kern.sysv.shmmax kern.sysv.shmmin kern.sysv.shmmni kern.sysv.shmseg kern.sysv.shmall kern.sysv.semume kern.sysv.semmsl kern.sysv.semmnu kern.sysv.semmns kern.sysv.semmni kern.maxfiles kern.maxfilesperproc kern.maxvnodes
$ sysctl -w
And copy the key-value from the list above (ex. kern.sysv.shmmax=4398046511104)
$ . /Applications/IBM/informix/demo/server/profile_settings
$ dbaccessdemo
$ dbaccess
$ sudo chown informix informix
$ su - informix
$ cat /Applications/IBM/informix/demo/server/profile_settings
$ cd ~ $ vim .profile
$ . /Applications/IBM/informix/demo/server/profile_settings
$ oninit $ onstat - IBM Informix Dynamic Server Version 11.50.FC2DE — On-Line — Up 00:00:09 — 41756 Kbytes
$ onmode -ky</blockquote> $ onstat -</blockquote> shared memory not initialized for INFORMIXSERVER ‘demo_on’
Tags: informix, install, mac, osx, snow leopard
For Father’s Day this year, my family gave me the gift of a stereo Bluetooth headset. I had been asking for one since the iPhone announced support for A2DP headsets. (Basically, simple stereo headphone support.) The one I got was the Plantronics Voyager 855. I can’t speak highly enough about it. There may be sets with better sound or build quality, but I haven’t had any problems with the set itself. And at just over $30 it is far cheaper than most. Listening to podcasts or music while mowing the lawn or whatever else is fantastic. The combination of in-ear buds that block out external noise and the wireless connection to the phone—I can’t believe I lived without it for so long.
However, the iPhone’s Bluetooth support is not the best. I have an 8GB 3G, and had a lot of trouble with the audio cutting out. Worse, the same was true when I was on a call. I could usually hear just fine, but folks on the other end would tell me that my voice was cutting out. I was starting to blame the headset and was preparing to buy a more expensive model.
Fortunately, I noticed two important things. First, the podcast/music audio cutting out tended to only happen when the screen locked. This was true whether or not I pressed the lock or let the phone auto-lock. Second, I noticed that Apple’s iPhone OS 3.1 update mentioned attempting to fix problems with Bluetooth and wireless (Wi-Fi). In their case, they were trying to improve Wi-Fi performance.
Because of this, I decided to experiment a bit. I disabled the Auto-Lock feature and disabled Wi-Fi. Suddenly, I had no more skipping and cut-out problems. People said calls did not cut out either. I tested this way for about a day. I was able to get the audio to cut out by launching a CPU-intensive app, but only during the launch. Once the app was running, the audio came back with no more problems.
After that, I re-enabled the auto-lock. I locked and unlocked the phone. Still no cut-out problems. I then turned Wi-Fi back on. No cut-out problems. Then I locked the phone. Bingo! Audio started cutting out again. I disabled auto-lock, but the problem was still there when I locked the phone. Finally, I disabled Wi-Fi and turned auto-lock back on. No more skipping or cut-out problems.
It turns out that the iPhone is built such that Wi-Fi and Bluetooth share an antenna (presumably to share space). This causes problems when both are on. Apple seems to have found a way to manage this most of the time and even released updates to improve Wi-Fi performance. However, as has been true of iPhone Bluetooth support all along, they seem to have neglected to do the same for Bluetooth. Specifically, something seems to happen to the Bluetooth power (and possibly the Wi-Fi power) when the phone is locked. The combination of signal degredation from both being on and the phone being locked causes the problem.
The moral of the story? If you want to use a Bluetooth headset, disable Wi-Fi. If you want to use Wi-Fi, disable Bluetooth. That will get you the best performance. Now back to enjoying my wireless music while refactoring.
Tags: bluetooth, headset, iphone, problem, wifi
The one or two of you who actually come to the site to read these posts may have noticed that a few weeks ago, I added a link to Improving Podcasts in my sidebar. Allen Hurst, I, and a few other Improving employees have started producing a bi-weekly (every other Tuesday) podcast covering software development topics.
We have three episodes produced, and the latest was posted just this afternoon. (It may take some time for it to show up in iTunes.) The topics to date have centered around Agile projects management and development practices. Head over there, listen, subscribe, and please provide feedback. We really would love some positive feedback in iTunes, but to suggest topics, ask questions, or invite yourself to join us, the best place is the web site itself.
Tags: agile, improving, podcast
I just can’t say how much I agree with this. One of my favorite things about Agile methods is their ability to find problems quickly. The problem is that it makes it very difficult to sell to folks who are used to methods with slower feedback loops. I can think of several projects over the last two or three years where the team exposed significant problems very early on in development.
In one case, we were able to pinpoint a major domain modeling problem early on. The customer kept phrasing things as though the application centered on one concept. Through a very early (iteration 2 or 3) demo, we were able to discover that this was due to thinking of how the system being replaced worked. In fact, what the customer’s business really needed was to be able to focus the system on a completely different concept. Because we found it early, we delivered a much better and more valuable system.
That said, the point of the linked post — and this one — is that software projects will fail, Agile or not. While we often sell Agile as a way to get to value quickly, we should also sell the other side — it also is a way to get to failure quickly. And that is a good thing.
It occurs to me that we talk about something similar in Episode 1 of Improving Podasts. What? I haven’t mentioned that yet? Hmm…