Yeah, right, Steve Balmer, yell for developers, but without performance they're worthless!

Two performance issues today: for some reason the picking slips being generated from our ERP system just crawl out of the computer, and the time it takes to make backups of our database has increased by 50% in the last week.

The picking slip issue turned out to be an indexing issue. After an hour of digging around in the source code, running the program with timer displays included (for some reason the wonderful profiler included in Progress decided to only show me performance on a couple of procedures - and those were not the ones I was concerned with), I tracked it down to a single statement, verifying whether a pick slip number had been used before by a pick slip, or by an order. The last search was the killer: it took about 3 minutes on our test box to search through all orders, since there is no index on pick slip number on the order table.

Since the check seemed extremely redundant (as long as you don't have two PPS's with the same number, I can explain to a user that the PPS number stored in the order is useless if you've deleted the PPS), I removed the check on pick slip number in the order. Instantly the time it took to generate a single pick slip went from 3 minutes to 0.7 seconds. Worth the change I'd say.

Unfortunately the supplier of the ERP informed me that it might not be a good idea to remove the check, and the newer version has an index on pick slip number in the order table. Oh well, as soon as they send me the exact format of the index, I guess I'll put the check back in and add the index. Even though I don't see the point. I'm flexible (especially on Fridays).

The second performance issue is a lot harder to determine. There doesn't seem to be any changes that have taken place over the last couple of weeks, but nonetheless, the backup on production takes much longer. It even takes longer that on our test machine, which has the same size and information.

One of the things that could have caused it was a fairly full backup disk. However, after cleaning up, it just took as long as it did before. Another reason could be that one of our programmers is running some scripts to create a new Cobol database, but he swears up and down it isn't run during the backup hours. The last suggestion was a runaway process, but nothing jumps out.

To determine the bottleneck, I've requested a copy of SARcheck, which analyzes the output of SAR and tries to compile a shortlist of issues with the systemit has run on. The copy should arrive sometime early next week, and I'm curious to see how screwed up our servers are in their eyes.

It has been a while since I wrote in the journal, but I'm currently researching some stuff that might warrant an entry, if only to collect my thoughts on the subject.

I'm trying to develop a relatively simple program, using Progress V9.1D and ADM2 smart objects. The program maintains three tables, a list of warehouses, a list of requests, and a list of request-lines. All of these have a 1:N relation to the next item in the list.

The warehouses are not modified through this program. However, the requests are. The main modification done at the request level is deleting the request, so a new request can be generated. When a request is deleted, all request lines of that request need to be deleted. When a request line is deleted, there might be an order line record that needs to be deleted as well.

The problem is how to store this logic. I've come up with a couple of solutions:

Use one SDO (Smart Data Object) per table, and store logic in the SDO's

• This potentially has the problem of duplicating logic. If I delete the request, I have to loop through the request lines, delete them, and delete the order line if there is one. If I delete one request line, I have to delete the order line if there is one. Since they are separate SDO's, I cannot call one from the other to invoke existing logic.

Use one SDO per table, combine them into a SBO (Smart Business Object), and store the logic in the SBO.

• This has the advantage of being able to use logic from a lower level SDO. Since the SBO has knowledge of both the request and the request line SDO, I can call a procedure inside the request line SDO to handle possible delete of the order line. So as long as we use the SBO, data will be consistent, but as soon as we stop using it, all bets are off.

Use database triggers to store the cascading delete.

• The database trigger would fire whenever the request is deleted, looping through all request-lines and deleting them one by one. The database trigger for request-lines would take care of the order line.

I'm beginning to lean more and more towards the database triggers solution. In various discussions on the PEG people discourage the use of database triggers, unless they are used to maintain database integrity (or to prevent orphan records lying around). For anything else you should use SDO's or SBO's, or, with version 10, ProDataSets.

Maybe I'll have to sleep over it tonight, and we'll see what the morning brings.

In a month and a half since the last journal entry a lot has happened on the SCO-vs.-the-rest-of-the-world front. RedHat has sued SCO back, in an attempt to prevent them from spreading more FUD that will hurt RH's business (i.e. Linux!). IBM has found 4 patents that SCO OpenServer is infringing on. SuSE is joining in the beat-SCO-to-death fray as well, sueing them overseas.

Meanwhile, SCO is trying to feign innocense and surprise. The killer is the reply to RedHat's lawsuit, saying they were surprised. Ha! "Hey! Somebody is sueing us! That's not right!"

As one /. reader aptly commented: "Get the popcorn, this is going to be fun!"

ZDnet has a story where Richard Stallman explains why SCO is using terms in a confusing way, and how the GNU project protects itself from just such abuse of terminology.

I ran across two books the other day, that looked very interesting:

The first book describes the development of the Segway (codenamed Ginger), "Code Name Ginger: The Story Behind Segway and Dean Kamen's Quest to invent a New World". A very interesting looking book, not in the least because it shows how for example Steve Jobs was involved in the Segway.

The other book describes the first cross-country trip by Dr. Horatio Nelson Jackson, "Horatio's Drive". This book is as of today not yet released, but there is a website Horatio Nelson Jackson and The First Roadtrip. It sounds like a very adventurous story, with Dr. Jackson betting $50 in 1903 that he can cross the US in an automobile in 90 days (correections welcome). A PBS documentary is in the make about this adventure, and will launch on Monday October 6th 2003 at 9PM ET on PBS.

Today's the day for SCO. Will they try to hang IBM, or will they weasel their way out of it? Will IBM be hanged without a fight, or will the noose slip over the other neck...?
No news so far except for an article on Yahoo Business roughly describing the origins of the conflict, and that there probably won't be any action until Monday the 16th.
Interesting is that some analysts say SCO's probable course of action will be to seek an injunction against IBM, while SCO says they may do something else. FUD or do they have something up their sleeve? Like a buy-out offer from IBM?
I guess we'll have to wait and see.

Well, that's what it looked like. Took me friggin 3 months to see it. Sigh. I guess journals just aren't for me. I've never had the inclination to write stuff like "Dear Diary" or such.

Maybe I'll get used to it.

Wow. My first attempt at making an entry in my /. journal. I can't wait to see what it will look like. :)