Oh boy. Yesterday I said it starting off warm (13°C). That was just joking. Now Today, it is starting off warm. 22°C at six. And getting warmer all the time, to 35°C again. On the attic I had 44°C in the evening.

We did hit a wall with TeleSales. A big, ugly concrete wall.

On the AS/400 the field names in the database are all 6 characters long and in uppercase due to a limitation of the RPG/400 compiler (fixed format statements based on old 80 column punch cards). Progress is a less dated language allowing long field names. Using the Progress V8 we translated all the fields from their AS/400 format (ex ohadno) to a long format name (addr-no) without problem. Now, with Progress V9 the conversion seems to be a problem.
The only solution we see at this moment is renaming all the fields in TeleSales. That means changing all the programs. Ronny is as happy as you can guess.

Theo is not in the office today. He sometimes works from home but that is usually on Wednesday so I didn't know if he had a day off or if he was working (he didn't react on mail from Jan so he probably had the day off). He did inform me when he left yesterday evening but apparently he did not inform anyone else. Jan, visiting Germany, reported a few bugs (to be solved immediately of course) but, with Theo not in, Ronny was a bit rudderless. He had some questions and some decisions had to be taken. This did not sit well with Jan and Wilbert.
Some firm discussion will follow one of these days. The only real problem is communication but that is often the biggest issue when deadlines and bugs are around

I finished a first draft of the correction program.

 

On his notes Tom explains how he is going to move his domain from iTool to his own local machine.
I moved away from iTool to Masset, a local shop, over the weekend. Toms four step method did not apply to me mainly because I am not hosting my own site.
I think that Masset was a bit too enthusiast to get me over though. I asked a quote. Got it ten minutes later, same price as iTool for same size but with wider, low profile tires, (I mean bandwidth). Told him I was actually interested and about ten minutes later I got a form from NSI. This was fully filled in for transferring the domain, all I had to do was send it back.
That was step-1
Step 2 is obvious, Wait. Whenever computers are involved that is always the second step <g>. Although I get the feeling that Masset did cut out this step.
Step 3 was probably done by Masset for me. I haven't got a clue what a Zone record or an MX record is.
Yea, step 1 and 3 (maybe 4 as well) all done by the new hosting company. I only had to nod and return a mail.
BTW while changing over from iTool he also transferred the domain registration from NSI to Joker. Which means I will save a bit on subscription next year. Talk about service. (Since I mentioned Joker to him he is not using NSI anymore).

Because Masset was so enthusiastic about all this the domain got transferred before I had a chance of getting something uploaded to the server. I didn't even had an IP number yet (was posted half an hour later).

While uploading and testing I got some certificate messages and file-not found errors but now I can see my pages again. The main (only) difference that I notice is that now I have to add the WWW. at the front. But maybe that is only necessary until the DNS change has percolated trough.

PS If the DNS change hasn't propagated yet you can look at 216.87.223.206.

Oh, yes there is still football.

England - Roumania : 2 - 3
Portugal - Germany : :3 - 0

I didn't watch TV and I missed the news so I don't know what ramains of Charleroi. Probably just some intersting ruins.
And some journalists have been caught bribing 'suporters' (by buing driks or distributing fireworks) to get more interesting 'news'. Just as I expected.

At last a break in the weather. Still warm 20°C but with lots of clouds on a blue background. While predominantly sunny the temperature is not pushed over the top. And a few light showers cool down the evening. Just the type of weather I like best.

We applied all possible and impossible means to break the wall . After the dust settled the wall still stands, hardly scratched.

While Wilbert and I were spilling our time Ronny stumbled over another obstacle. In our database all (~most~) key fields are filled with uppercase values, the AS/400 is case sensitive in most places (except for its command language). In TeleSales we have a few filter screens where the user can restrict a selection on non-key fields. The data actually contains lowercase but the querry-argument passed by Progress is always turned into uppercase.
A similar problem was solved a few months ago however in that case it was a sub string operation. Now it is a database access and the solution we have means that the file will be accessed without using the existing index. This is of course killing the performance and unacceptable on any substantial file. (The case at hand is just a small file so it's bearable, a worst case of about 200 records but we have much bigger files.)

In between I check out how the prices are calculated for return orders with a related order. Depending on the way some codes are set up (local responsibility) the price and conditions of the original order are used and only adapted for the possible different quantities, or the prices are reloaded from the item file (or price-list or contract or ...). For normal returns the original price (from the order) should be used. In Germany that doesn't seem to be the case.
Maybe they have their codes not set up correctly. We will see tomorrow.

Again no time was left for the VAL adaptation program.

 

Football :

Spain - Yugoslavia : 4 - 3
Netherlands - France : 3 - 2

My site transfer seems to be more or less complete. Brian noticed a broken link to the Calendar (I didn't know any one else went that way). Somehow the leading 'C' became capitalised where it used to be lowercase (I upload from a Win98 box so you can guess where that C came from). On a UNIX (Linux on Cobalt Raq) that makes it a different file.
I expect some more of this type of errors. Sadly I am not using FrontPage or another HTML tool so I can only blame myself.

And the www. is no longer required. I mentioned the problem to Masset and I got a mail late yesterday evening that he had changed something on the server making it optional. So there is no need to change any bookmarks or links. Tom had already changed the daynotes.com links and I had changed the links trough out my site. All unnecessary but there is no need to change back.

We have got a webserver sky and ... I meant A patchy sky, lots of loose clouds, throughout the day with a few rainy spells. And a reasonable to low temperature (14°C in the morning is reasonable and 20°C at noon is a bit cool for summer).

I did post yesterday but I forgot to update the redirection. But don't bother looking, I just said I had too much work.

And would you believe I only remember one thing about it all. I think the hot nights have an impact on my memory.

What I remember is that we (Wilbert and me) found a problem with the RPG IV system.
As I mentioned a few days ago we had a problem with V9 of Progress. The intriguing thing was that the problem only occurred when we changed the field names using the RPG program. Doing it manually or using queries caused no problems. Thing is neither of these methods are acceptable in the opco's.
The root of the problem lies in the RPG IV language. The files containing the field names contain a lot of binary defined data. In the program file definitions are loaded at compile time, conserving the data types. The moment a record is read the binary data is converted to a packed data type (that is the default numeric data type in RPG). Later the record gets updated in the file and the internal, packed data is converted back to binary format. This converting happens even if the fields are not used, just a read and an updat statement are enough. A binary field of five bytes long gets converted to a packed field of five bytes long. Such a packed field can only contain 9 decimal digits and a sign, binary cannot contain a sign and may contain more than 9 decimal digits. Sometimes the conversion produces the correct value, sometimes it doesn't.
Using a few uncommon programming tricks we beat the RPG into conserving the binary format even on its internal fields.

Yes, that big ugly concrete wall was rendered to dust. It only took time, perseverance, sweat and a bit ingenuity.

After that I worked a bit on the recovery program.

After dinner I went to my brother, for spraying the potatoes. And I assisted him in connecting to the internet. The main problem is that I warned him to be careful with what he does once he goes out on the web. I warned him too firm. He had tried to connect but had shied away from pressing the "register" button. Without registering at you ISP you don't get far on the internet :-)
After registering (and testing) I assisted in setting up his e-mail account. Again explaining things and testing-demonstrating the lot.
I let him do all the typing and clicking, and only explained all the terms he didn't understand. He now is an informed internetter. And I lost the evening.

 

That was Yesterday in a Nutshell. <G>
So what happened today?

 

I finished the correction program. Well, it is not finished yet but all the file accesses are ready, I only have to work out which fields must be filled with new values. I need Jan to assist me here so I prepared a list which we can run over next week.

Halfway trough the morning Wilbert came to inform me that, after a final test the wall breaking program (field renames) did work correctly even on the production environment.

And then I spent the whole afternoon with a problem from Norway. They had a decimal data error (crash) in the price maintenance routine. After slogging trough the logs and combing the data I finally found the problem and the solution.
While trying to apply a price maintenance request with no price maintenance object selected the activation program doesn't find the JE records (and doesn't even look for JD records. It does however tries to print something with data from JD on it. And it fails with a crash.
The solution is easy, just add an initialisation statement. After documenting the whole lot and getting the source from archive I notice that the problem was already solved some months ago explicitly for them. The solution is included in r7v08 mod-4 which they haven't installed yet.

Sigh. Lost time.