Daynote ,Svenson

Sjon
 
-- Home -- Links -- Sjon -- Calendar -- The Gang -- The Undeniables --

  -- Yesterday -- Week view -- Tomorrow  

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?


Adios

 
-- Yesterday -- This week -- Tomorrow --

-- Home -- Links -- Calendar -- The Gang -- The Undeniables --
--

Mail Me
Svenson © 1999

If time were money I'd print my own. >!-- but what about inflation -->