Week 03, 2000 ,Svenson

-- Previous week -- Most recent -- Next week --

MM-xvii     Monday

2000-01-17

The "almost" drizzle that started yesterday has been going on ever since. The result is an uncomfortable, warm (5°C), wet gray day. I don't want to exaggerate, but the Saskatchewan weather sound inviting.

We came up with an architecturally feasible solution for a problem we are having with Progress.

The problem.
In Progress there is a limit (64K ) on the action segment for a program. All the actions (assign, call, etc.) take up a part of this. On our Order Entry screen we have hit that limit several times. Up to now Ronny has been able to solve it by moving code out to external procedures but we are now at a stage where this is no longer possible. Each new feature or required function that must be added will mean something else has to go. Especially painful is that the new release of Progress and, even more so, Pro Shield that we depend upon, have added functions and actions to the code that gets included. At this point we cannot even solve some known bugs.

The solution.
The Order Entry program, now uses an updateble browser combined with an (updateble) viewer and a dashboard (and a button bar and a menu and a kitchen sink and .. oeps, slight exaggeration, we didn't do that request ). We can replace the updateble browser with a separate data-entry dialog. That will be an external procedure so (almost) all the triggers can be removed from the browser and a lot of duplicate functions can be removed as well. We convinced Peter about it (now that took most of the morning) and we got Theo in on it as well. Jan isn't convinced yet but he understands that we need to do something. he will propose it to the opco's and they must decide. Of course they want to keep the updateble browser, combined with the separate entry screen and a bunch of new function. (Belgium - yes those that complained about the performance - now want to get the lines calculated while they are entered. That means recalculating the order whenever they hit enter. If it sounds like shooting down the performance it is. With a 16 inch gun. Point blank.) The only way we can do that is by rewriting the whole bunch from scratch in another language.
No way.

The invoice printing problem that I solved last Thursday for Belgium still hasn't been sent. Theo wanted to test it and he finally came around to doing it today. We only have one problem here in Venlo and that is that we don't get anything printed from the invoice-printing program. Nada. Checking the records everything appears to work correct. Theo asked Jan and Pieter for advise but they don't seem to be inclined to help much. And that while he is doing the job they should be doing. Yep, once Theo gets worked in the programs will be released without testing again. Just like in the good () old times.

During the day I didn't have time to check up on the other daynotes. I only got to Toms last post.

Due to an accident, a truck completely blocking the road, I lost three quarters of an hour. I got home after eight. I have been casting my frame based current page into a presentable format but while doing so I came upon some things that I should try out a bit deeper before actually publishing (ex do I need two <frameset...> tags). I wanted to do so this evening but ...
Yep, time's up.

MM-xviii     Tuesday

2000-01-18

The same watery stuff keeps descending from the same gay clouds. All the wile keeping the thermometer pegged at the same dull temperature.

One TeleSales problem is found and solved. When adding a new address some fields are filled with default values (language, VAT code, etc.) which are maintained on the AS/400. The problem was that the language code, which is defined as a two character fields was filled with 'USA' (three characters). Using the standard maintenance programs that cannot happen, but of course there exist tools (SQL,DFU,...) to get behind the standard programs. In TeleSales putting three characters into a two character field sometimes is a problem (only if both fields are direct database fields), it produces a warning and truncates the value. Normally we trap these warnings where we expect them. In this case we didn't trap it because there is no regular way to get it wrong. Of course Americans never play by the rules.

One problem found and solved doesn't however mean that there is one less problem remaining.

I got a call from Belgium about a strange order. They had an order with two order lines, the order was in status Shipped. One of the lines had its invoice date already filled. This is strange because that date is only filled in the invoicing program and after invoicing (and filling the date) the order status changes to Closed. Digging a bit deeper we found that the order date of the one line was somewhere in October (99) while the order header and the other line were, as expected dated in January (00). They had run the conversion of the order from their old system to our database in October so our first suspicion was that some stray order lines had remained unnoticed and were now being picked up.

While testing that here, in the OMSI-3 environment I found out that that was a distinct possibility. If for some obscure reason an order line, without header and with an order number greater than the highest actual order remains in the order lines file (OL) - this cannot be done with the regular programs - it will be picked up when a new order is created with that order number. This is dangerous and tricky. The user can see the unintended line but he doesn't know its origin, it shows up in exactly the same way that contract-defined lines appear. The result is that, once the order is released (and the user forgets the line) it is impossible to know if the line is a real line, to be shipped, or a stray line to be removed.

After a few hours of searching and pondering we remembered that they don't use OMSI-3 but TeleSales. Ouch, tag about and sail another course.

And here we noticed that a specific function, Copy From History, produces the same result. The order line is copied, exact, including the dates, from the historic order. The function is intended for, among others, a client who call and says "Do me the same as the last order for xxx" . "The same" of course should not mean the same creation date, or the same order date. A badly specified function, executed literally >!-- the head down and code like hell symptom --> and virtually untested. Well it was technically tested and found to conform with the design (copy from history), and no one checked it against the 'intended design'.

Any error costs but an early error (design) costs more than a late one (implementation). And finding it after running half a year in a production environment is double trouble. The dates are used to build stock and sales statistics. Who believes the data. Or trust the programs.
ps. I must ask Robert to check the history order. If it contains only the line with problematic dates everything is OK. If however the second, correct line is also copied from history we got a different kind of problem.

This doesn't seem to be a good week for trafic.
Yesterday the road was blocked by a truck, with a trafic diversion along some small byways, costing me three quarters of an hour. Today an other accident, on a road I don't take caused a problem. The trafic was diverted to the road I do take. Doubling the trafic density does more than double the travel time. I lost half an hour. Lovely :-(
So no time to test out the targeting (see yesterday). I did notice something strange though. The #last used inside a page works different from the same #last appended to an external url to the page. When using Netscape, in Opera both links do the same.

I just realized I created a small black hole by trying to put up a serial story on the tomorrow pages. It grows on a daily basis but for example as I write tomorrow's part ( to be posted now) I don't know what I will add after that. I have no story line, no plot. And I am not a writer. But I cannot stop now, can I?

MM-xix     Wednesday

2000-01-19

Still cloudy but it is finally dry and a bit cooler (3°C). With the sun breaking trough the cloud for only about half an hour at noon (shining straight into my screen) it is not yet cheerful.

I lost the day mainly in discussions with Ronny or Theo.
The only thing I consciously finished was the documentation of the Copy From History function in OMSI-3 in order to help Ronny build it correctly in TeleSales.

Unexpectedly there were no trafic problems today.

I started assembling an other computer with spare parts left over. The only new parts are the case and a network card. Now I ordered an A-Open case but there was none available when I got to the shop. As this was not going to be a vitally important box I just asked for the best case he had lying around. What I got was a featherweight box with some sharp metal inside. Yeah, that is called the cutting edge of computing. It is a mini tower with almost no internal supports. On the one hand this makes for a surprisingly roomy interior but on the other side for an exceptionally weak thing. For example the power supply, which is badly positioned over the memory and I/O connection of my AT size main board, bends the backside outwards just by its weight.
I guess this is the last time I get anything else but an A-open, even if I have to wait weeks on it.

The processor was one I got back some months ago, while I was assembling Aria. It was defective and I did send it back. After a few weeks I got a processor back as 'replacement' but I suspect it was actually the same part. Because I hadn't written the serial number down I was not sure and having completed Aria with another (faster) chip, I chucked the returned chip in the spares bin (well actually I inserted it on the mobo that I had as spare) untested.
I installed the mobo with the chip, added a display card and powered the thing up. To a blank screen and some diagnostic beeps which indicate a death processor. I'll have to get another one in the weekend.

MM-xx     Thursday

2000-01-19

It's mainly cloudy and dry, with temperatures down to a cool 3°C. With mainly dry I mean there were a few short patches of rain but nothing remarkable. That there was no sun at all isn't remarkable either.

We got into a discussion, first with Jan and Pieter included but continued later with only Theo and Peter (and Ronny of course). The issue this time was the way we handle offers. We don't have a separate program to create offers in TeleSales, only an order entry program. At the end of entering an order the user can decide to save it as either an order or an offer (or even as a contract). The problem is that we store offers in different database tables from orders.
For an order we save (amongst other things) the unit_sales_price, the quantity and the taxable_value. On screen we present these fields in addition to the net_value (unit_sales_price times quantity) and the amount of the conditions (net_value minus the taxable_value). For offers we only store the unit_sales_price and the quantity, so we cannot display the taxable_value not the amount of the conditions. Currently we display zeroes. Of course we can recalculate all the values, and we do that just before saving the order/offer or when the user requests it via a button.

This seems to be confusing for users. And really it is a bit confusing. They are entering data and just before they save it all the values are correctly displayed. If they subsequently open the order/offer again some of the data seems to be lost sometimes (if it was saved as an order all values are saved, is it was saved as an offer some values are lost). To add to the confusion it is possible to have order lines with zeroes as correct values (somewhat like Tektronix giving black toner for free with its colour printers, if you order it you get zeroes for prices).
After more than two hours discussing we came to the decision to recalculate before displaying an order/offer. I assume we all knew that that was the only way to get the correct values displayed in all conditions. It only took about two hours to get it worked out.

While we were discussing Robert called from Belgium with a problem. When I finally called him back he had solved the problem along with some other problems. We send out PRS'es (Problem Report System)....

<asside> it should be a PR from Problem Report but they are store in the PRS and are identified with a PRS-number which consists of "PRS" followed by a five digit number. So we are always talking about a PRS in stead of a PR </asside>

Yea, I like that. You just wait and the problems disappear.

MM-xxi     Friday

2000-01-21

Again cloudy and 3°C but a bit less dry then yesterday. I didn't see the full solar eclipse - well if you stand on the moon it is - but only some part of the last phase while driving to Venlo. Finding a break in the clouds for a view to the moon while driving at 130km/h is not simple. I did get a few glimpses but trough the clouds everything remained hazy. (No, that haziness had nothing to do with my speed) (I think).
It is now 22h15 and looking out I can confirm we have a full eclipse again. Or is this just thick clouds?

Ronny did implement the changes we discussed yesterday along with some minor other changes. While I started on the next V9 project. I created the Database file for the Project and Consulting Administration (PCA from now on). With some luck I do the first program on Monday

Pieter and Jan came in again to discuss some issues concerning the Quality Control system (Customer Complaints module in TeleSales). After a somewhat heated argument about priorities Pieter laid down his requirements and discussed them with Theo. We (Ronny and me) were not involved but they discussed the whole time there and then, in the middle of an open plan office. Royally shooting our concentration.
Thanks a lot guys, but there are separate rooms for such discussions.

Lots of trafic but no pileups so I am home late, about 20h00, but not exceptionally.

I dug out an old chip from my spares bin ,well two years is really old for a chip, to try it in the box I assembled on Wednesday. This is an AMD K6, capable of 200Mhz, which, coupled to 64MB of RAM and a 6GB disk, should be capable enough for a Linux box. I just inserted the chip, rejumpered the mobo for a 66MHz bus and it starts up normally; until I get to the "no keyboard found, press F1 to continue message". I don't have a keyboard yet so that is not surprising. I have no idea what is left on the hard disk, but whatever it is I am going to wipe it clean and dump Linux on it.
Tomorrow

MM-xxii     Saturday

2000-01-22

It has been raining on and off today

I have been struggling with my stomach today. nothing I put in would stay. Combined with some awkward moments at the toilet (of the which side first type) this has kept me occupied. I don't think it has anything to do with flu cause I have kept a reasonable temperature (except when kneeling in front of ...). I hope to be better tomorrow.

I hoisted myself up to the attic just to post this daynote. While I normally open the trapdoor with he stair without effort it had me straining today.

MM-xxiii     Sunday

2000-01-23

We got cool (2°C) and dry weather. Well only one short shower to brighten up the day.

I didn't think it would do me good to go running after Yesterday, so I slept in till about eight. Just in time to go to the baker for fresh breads.

Since I moved computers up to the attic I have been working without a network. To that is was intensively used before, with typically only two or three computers connected at any time. Now that Cindy (at my brothers place) seems to be behaving normally I have Oswal and Miona on the attic on a permanent basis so I wanted to connect them together. Miona had been connected to Harper before I moved it up so I had only to setup Oswal and connect them up. After vainly trying for more than an hour I gave up on Oswal. It only wanted to see itself on the network, and the Help files in Win98 are extremely helpful (a hum). They propose the obvious things (is the cable plugged in, are the settings correct (without telling what is 'correct' of course) etc. ). Digging any deeper results in a redirection to "your network manager". If everything goes right you don't need the help, if anything goes wrong the help is not really helpful. Only when I came back after dinner did I check Miona and noticed that the network card was not configured. Duh. It had been connected to Harper but after that I had experimented with Linux and only after hauling it up to the attic had I reinstalled Win98. Without networking. As I don't know what type of card is installed I will leave networking for another day.

Last week I got a cheap digital camera but I didn't try it out. In stead of playing network manager I played a bit with it.
The camera is a Trust Photocam LCD Pro, featuring a 810K CCD, a 3.5F, 5mm lens, a 44mm LCD and 4MB internal memory. It should be capable of VGA and XGA resolution photos in three quality settings. It connects via a serial or a USB cable. At a price of 12000BEF (under $350) this is not too bad, especially if you remember I got it at half that price.

So here is the first pictures.

First, my main desk and work are.

Next, we have Miona on the attic.

These pictures were taken at VGA resolution and Fine quality. More as I get to know this box better.