Clear and cool (9°C) morning but without the expected mist. The sun is now so late that she only pops over the horizon when I am well on my way to Venlo. Shining right into my face.

Wilbert came back from holiday and gets besieged immediately by Ronny and "Jempy" from the TOS team. Some time later he came to "complain" cause I had filled up his mailbox. Oeps. I did send jokes, typically one or two a day, to a list so now he got some thirty odd jokes to work trough. Hey, happy back Wilbert <G>.

I got a fairly good day, I mean very few interruptions, done. Not very productive mind you.
Unlike some people (say hello Brian <eG>) I like to work on a Monday. I have a lot of memory under my skull and most of it behaves like computer memory. When I stop refreshing I forget in about 30 nanoseconds (see my Bio.). Now this 30 ns is an average, some bits of information get lost faster while some remain quite a bit longer. Typically after a weekend my brain is completely reset and I tend to look at the problems differently.
I have been thinking about the Free Of Charge problem a few days now and I even had coded a few minor changes. The problem is that the same changes in order entry for OMSI-3 had to be built into TeleSales and (probably) in TOS as well. And then there are a few other modules that create orders as well. A second problem is that a user can select the wrong transaction type by accident, immediately correcting the error may not cause data to be lost.
What I came up with today is a solution that alters the calculation routine. That way all modules handle Free Of Charge in the same way without adding and changing each and every order entry program. So only one change is required and when it works from one module it will work with the other modules as well. It's a bigger adaptation than originally planned but this way its easier to test and simpler to adapt later. This means a big setback for the bug-farm :-°) . It also means that I got to do all the work :-(

 

Last Monday I stopped to maintain my daily pages and only kept the week-page up to date.
I expected some mail. And I got nothing. So either all three or four readers got the message last week and approved. Or nobody noticed because they were already reading the week page.
Maybe I should find out how to check my statistics.
I am still posting once a day in my routine and writing the daynote is just the same. I do gain some time by missing out a few copy operations and, more importantly on the daily roll-over. Now the page and all the links thereon remains the same, before that I had to change the links on a day page each day. A bit like a week-change each day. And I also get to upload a lot less. For example week-32 has a week page of 25k but the combined daypages are 39k. With an average just under 7K for the daynote and 4k for the 'tomorrow' page and 4k for the day-redirection (that is 15k less each day) added to that the 4k week redirection and the varying week-page (8k on Monday to about 25k on Sunday).

So I gain a bit of time, loose a bit of administrative chore. And nobody complains. Something must be wrong with this <srG>

Dark ominous clouds cover the night sky leaving a narrow band of early daylight trough, close to the eastern horizon. The sun gets some rays trough that gap and uses these to break open the rest of the black mess. By evening, when the sun retreats however, the clouds are back in force. With a bit of rain even.

We noticed a calculation problem in TeleSales. Normally all items have a price record in the CP (Cost Price) file. The calculation picks that up if there is no list-price or contract-price or any other type of special price. If for an item no price is found the calculation stops short and passes an error back to the calling program. Because this only ever happens to a corrupt database we never get that error.
Just to prove you should never say never the TOS boys pick up the one corrupt record in the whole database application. During testing they compare their results with the TeleSales results and now they notice that both applications return zero prices. Which leads them to the conclusion that the calculation program is bad.
Of course they are wrong. the calculation program is mine so it cannot be bad <g>. Which I proof by running that order trough the old OMSI-3 route where the correct message is presented.
And then I spend a few hours actually locating the origin of the message. Sigh.

PS
in hindsight this sounds easy but the only report I got was "the calculation returns zero prices for order nbr such and such" and it is only after tracking down the origin that I get the full CP picture. Yep programming is 90% detective work (and 90% testing, leaving just a little bit for coding. Which just shows a programmer must be more than 100% committed.)

The solution is that I will have to pass the error message trough the TS/TOS API so they can do an easy pick-up. Now that is quite some change both for me (pro017r) and for hem TOS and TeleSales.

While noting down that problem I get caught up in writing and massaging documentation.

Later we get into a discussion (including Theo and Pieter) about how the orders must be presented. Which requires yet another boring explanation into the workings of our system.

We have orders in the Order files (OH and OL), the working set, but we also store the orders in archived order files (QH and QL). The main reason for this split is to keep the active set small for good performance (there are a few thousand records in the OH/OL files and several hundred thousand in the QH/QL files). All the actions are done on the OH/OL files and only during the night the changes are copied over to the QH/QL files. All changes are copied over. The orders that are completely handled, including invoicing (with status CLOsed or CANceled) are then removed from the OH/OL files. The result is that all the orders in OH/OL are duplicated in the QH/QL
When you look up the orders for a client you initially get only the orders from the working set (so called 'open orders') and only on request you get the archived orders as well. Without displaying duplicates of course. OH/OL, if available, is always current.

For a normal, classic, application that is normal; You can educate/train the small set of users so they know how to look up orders. For a web application that is not good enough. When a users selects all his orders over a period he wants to see them all, both open and closed. And in sequence. That means that, for TOS the files must be merged. At run time. This will of course kill the TOS performance. And usability, no ones is going to wait over a minute to review his orders.
The problem is of course that nobody saw this early enough in the development. Planned delivery of TOS was early September. That is not going to happen is this type of problems crop up now.

 

For dinner Suzan cooked mussels with French fried potatoes. Which goes down well with a pot of beer. She peeled one potato too much and had it wrapped in foil for tomorrow. Now that won't do so I apply a kitchen samurai and make some delicious potato chips. Served direct from the frying pant, spiced with tandori. (Don't make this when you have kids around or else you have to do it each and every day.)

I start out in Hasselt with just a thin veil of mist (expectable with a cool 9°C night after a rainy day) that is getting thicker as I go. In Venlo it's thick enough to blot out the sun, which was rising red-ly halfway there, completely.

Most of the day is spent in discussion with Ronny and in assisting him finding problems. And we do find some problems but none of them require immediate action.

Later, after helping out the TOS-boys with some problem he comes back and starts to lament the consistency and quality of the TOS program code. Again.
Almost every time when he comes back he does that. The main problem with the TOS programs is that they don't use the same naming conventions as used in TeleSales even though they were told to do that at the beginning of the project. The result of not keeping to our conventions is that they don't handle naming consistently throughout their application, sometimes mixing up field names (ex requested receipt date is named eReqDlvDt where we use Dlv for 'Delivery' and we have a Delivery date in the system). And where they uses common coding (calls to the server programs on the AS/400 for example) the are passing, apparently, wrong data.
This will be a hell for maintenance later. When we request them to change a field or label name they often refuse, telling it is too much work, especially because a lot of the code is being generate by a tool which would delete code when a referencing name changes. This means we will inherit a bunch of un maintainable code that we cannot simply adapt.
So Ronny whines about that and I always reply that he should not just air it to me but that he should note it down. I finally convinced him to start doing just that (direct in HTML no less :-). We will need such a document because once the project is transferred to us we will be expected to solve the problems fast and we won't be able to.
Put bluntly, we must somehow cover our asses.

Jan calls from Norway (where it is raining most of the day) with a problem in the trigger file. Several thousand record are in there that shouldn't be. After checking we find out they are almost all related to Consumable Orders. Jan does the checking but he is rambling on citing wildly different record counts. He is obviously mixing up production and test and other environments. After patiently listening in and checking some code on our own system we notice that most of those Trigger records relate to consumable orders that have been handled completely (shipped and invoiced).
The question I have is why don't we have this type of record in the other opco's. According to the code everybody should have them.

 

I spent most of the evening pulling Yaku apart to retrieve a small hard disk (2GB) for use elsewhere (read firewall under construction). I brought him back from Venlo where I used him originally for the GUI/400 project and later for fun, as a second PC. Yaku is an old AT mini-tower with minimal internal space so pulling out a drive means total disassembly. And, after reassembling I notice the drive remaining is jumpered as slave so the box doesn't want to start. And to reach the jumpers I have to remove the drive. And to remove the drive I ..... Yes.
All's well that ends well. After almost two hours of surgery Yaku boots again in OS/2. All without reinstalling, Just hardware juggling and stupid mistakes (like loosened cables, etc.)

And I just noticed I set the forwarding delay on the redirector to 100 seconds (for a test) and forgot to turn it back to 1. Oeps.

It's misty all the way today but still sunny once the mist has fled. It really is good weather to be out; sunny but not too warm (22°C). Ideal for sitting in an office behind a screen :-(

I have been getting a bit disorganized lately so I get my tasks straightened out again.

While explaining to Theo what I have been up to some synapses collide and stick in the right way. The problem Jan noticed in Norway ,lots of CO orders getting stuck in the rigger file, suddenly becomes clear. I mean I see a possible cause and, at the same time a possible solution.
Some months ago I solved a problem with the Consumable orders (CO). The problem then was that the CO orders did not generate an invoice. All the right steps were taken but they got stuck just before the invoicing. The culprit was the trigger file. For the CO orders a special trigger filling routine was (and still is) used because they must be skipped while building the statistics file and they may not show up in the consumptions or assortment files. To get that only the calculation flag was set low, all the others were pulled up. The trigger processing will delete a record when all flag are up.
The normal processing is first calculation, then invoicing and lastly trigger processing. So calculation pulls the last flag up. Invoicing finds a trigger so an invoice is created. Trigger processing sees all the flags high and deletes the record. Clear and simple.
Only that order of execution is not enforced so it is possible to switch the last two steps.
So calculation pulls the last flag up. Trigger processing sees all the flags high and deletes the record. Invoicing doesn't find a trigger and doesn't create an invoice. Clear, simple and problematic.
So I change the CO-special trigger filling routine to set two flags low, the calculation flag and the invoice-update flag. This one is intended for processing the statistics but if no statistics are created they will not be updated.
So now calculation leaves one flag low, so the record isn't deleted, so that the record remains and an invoice gets created. Fine. (and accepted by Jan).
Only the record is never deleted.

If I now change the invoicing so that it pulls the remaining flag high the records will be deleted eventually. I must propose that to Jan and then check if a correction program is needed.

The afternoon was spent transferring knowledge from the TOS team to us. Last week a general explanation of the applications working principle was given. And absorbed.
This week we get a more concrete explanation of the same principle but using real programs and real paths. Basically it is a demonstration of the management tools used to locate errors and an in depth explanation of the programming structure. Next week we should get a problem report to solve as an exercise.

The main thing for me is that I will have to learn how to juggle Javascript and HTML stuff. I know quite a bit HTML already but I haven't used it 'for real' yet. And I have just been looking for javascript stuff, I only know how to open a new window (hehe) and how to walk forward and backward trough the page history of a site. (Does anyone know a good javascript book? Something for beginners that need a rocket start?)
I haven't used layers or style sheets at all yet and I need to work with them.

Interesting times. But my Linux plans will suffer from all this.

 

Oh dear
Smoking will kill you, drinking alcohol destroys the brain, sex is not 'politically correct', guns and violence is being forbidden. And now we shouldn't drink coffee anymore. Next you get sued for threatening when you offer someone a cup of coffee!!
I slowly start to understand how the dinosaurs got extinct.

No mist but a complete cloud cover and only around half past seven it becomes possible to guess where the sun is. Later in the morning The clouds break up and run but in the afternoon they are back, dumping a load of water.

I composed a document about the Trigger file problem and how I propose to solve it and sent it to Jan for approval. He was in (I got a reply to something else) but apparently did not send me a reply. I take that as 'silent approval' and adapt the invoicing program. A bit tricky because I want to make sure I don't break anything else. The testing is even more tricky because the test database is becoming totally corrupt. And for some reason when I make a new order and try to get it trough logistics I only meet crashes and dumps. Something is really blown up in Logistics I think. I finally run the test on 'hand-crafted' (DFU+debug) data. Things look good so I pass the program on to System test for Jan. Things will remain this way until Jan tests and approves the change. The adaptation must also be done in V8 but I wait for formal approval by Jan.

While I spent almost the whole day on the trigger testing stuff Ronny gets into some arguments with Theo. The way things are going I think Ronny will be leaving soon. What gets at him hardest is that he has been working on TeleSales for about three years now. Mostly doing the programming work alone. In the beginning, with Peter as architect he got full support. Now TeleSales is finished, well not exactly finished but it is more or less stable and it is being used in production environments, which means very few new things have to be added. It is in one of the more difficult stages of project development, with multiple releases to be maintained and bugs that must be solved differently depending on the release. The bugs are becoming more difficult to track down and often lead problems are caused by conflicting requests and requests that go straight against the original (but undocumented) resign.
It is a difficult stage. And now with Theo being absorbed mostly in the new TOS application problems are not picked up swiftly and problems are not filtered as they were before. A lot of the 'problems' are not real issues and Peter had time enough to handle them, Theo hasn't got that time and so they pass on to Ronny giving him the impression that, suddenly his programs are not appreciated. He feels somewhat abandoned.

Aggravating the situation is that Koen is getting more time away from his projects and is now picking up TeleSales problems. He doesn't know the tools nor the application well enough to just pick up the work. He requires some attention but he has a rather difficult style. When he sees code he doesn't understand or code that he things is out of place he simply moves it, often with muttered comments about shoddy code.
Which Ronny takes personally.

Just before I came to the project a comparable situation had developed resulting in Mark being removed (being replaced by me). Which is why I think Ronny will leave.

 

Yesterday I gathered, from a side remark, that Pieter (leading TOS) sometimes reads my daynotes. And today Wilbert mentioned reading my site.
Which means I must be a bit more careful of what I put down here.

It rains most of the day, but it all but monotonous. We get rain in all forms and sizes, from drizzle to torrential downpour, with a few thunderclaps thrown in. To add some more variety we also got a few sunny, even bright moments.

Shopping. The power supply hasn't arrived yet, typical for Masset, when you order something that he doesn't keep in stock you can count on waiting several weeks. Of course each week he confirms that it will come in 'this week'. Not a problem if you know what to expect. I do bring a CD drive home and an AMD chip. The K6-2 at 550MHz is currently the slowest available and Steven doesn't intend to restock them. I have a spare Socket-7 board so it's best to buy now before the K6 runs out; And I pick some drive brackets up as well, to fit the salvaged 2GB drive in the old AT case which only has 5.25 inch bays.

Later I help my brother with transporting more building material for his greenhouse. And he helps replacing the washing machine. That means disconnecting and slepping the old one down from the first floor. Go to a shop and swap it for a new one. And then manoeuvring the new one back up the stair. Of course none of the fitted tubes are long enough so we have to use the old ones. Which means we have to take the new machine apart.

Much the same as with computers. Cramped and cluttered interior with sharp edges and inaccessible tube connections.

For diner I get some asparagus from the deep freezer, roll them in slice of ham, dump some cheese on them and then bake them for 20" in the oven. It is the first time I use the frozen asparagus and while still delicious you do notice a difference

Its dry in the morning but between six and eight we get 4 showers, quite heavy, interspersed by very clear and closer to eight even sunny spells. This pattern of sun and rain or almost rain continues trough the day but at a slower pace.

So it is dry but not too hot while running and I take the long course (with two bridges).

Peter is here most of the day; We connected up the washing machine Yesterday and we tested it today. Not an onerous task, just check for leaks and overflows regularly. Nothing goes wrong so we store away the packaging for a few months, if it keeps working that long we will get rid of the bulky packing stuff;
In between and afterward my brother works on the electricity on the attic and I scan in some of his documents, converting them into text which he will correct and adapt with his Psion while on the train.

In the afternoon I take an extensive break. Just like my brother (inherited?) I easily get blocked sinuses and, apparently yesterday I got wet wet and got caught by a draught. So I spend the day sniffing and sneezing. That typically only last for two days so there is no need for special treatment. I just cannot sit down, if I keep running up and down and typically busy physically I am not bothered too much by it.

In the evening my father comes back from his two-day trip. As usual happy but tired.

I make one or rather two of my typically improvised pizzas (basic dough, with a topping of onion, a handful of bacon and a load of mushrooms, all baked, with some choridzo slices and a good covering of mozzarella cheese ). The best praise I get is that he actually stops raving about the perfect salmon he had yesterday and call the pizza better.
There.