Daynote ,Svenson

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.

Adios