Mon
Tue
Wed
Thu
Fri
Sat
Sun

The Spanish problem is quite a mystery. In the end I got to a solution but what actual cause it stays a mystery.

The normal processing of the trigger file had canceled, at least tree times in a row, without anyone noticing it. It canceled because there was a duplicate record in the S3 file. After much filtering and sifting trough the files and a few sidetracking we found that the duplicate record, along with a few (actually 20 out of 47000 some) others that would have cause the same problem had we simply skipped the first one, belonged to a single collective invoice.

Normally when an order is processed its key is picked from the trigger file, which is filled by the feedback from OLI. The order is converted into a temporary invoice, in a special member (HIOM3). When the Trigger processing runs at this point (stage-1) a record (one for every invoice line) is put in S3 but without the actual invoice data as this isn’t available yet. When the invoicing is run all the temporal invoices from HIOM3 are converted into real invoices, in the HI/DI file. When the Trigger processing runs at this point (stage-2) the already existing records in the S3 are completed. For invoices that weren't processed in the stage-1 action, ex they were shipped later, the stage-1 and stage-2 are combined in one by the stage-1 program, the stage-2 program doesn’t run for them. When all stages are passed for an order/invoice the trigger record is deleted.

The situation in Spain looked as if, for most of the lines of one invoice, first the stage-1 was executed, producing invoice-less S3 records. At a later stage the combined stages was run, producing normal S3 records. And since then every run of the Trigger processing tried to run stage-2 for the invoice-less S3 records, attempting to produce a normal record. This already existed so the program falls over.

Short of using DFU I see no way to reproduce the actions. It looks as if someone backed up the Trigger file, ran the processing, ran invoicing and then restored the file. I don’t thing this happened although something like it could have happened during their conversion activities while upgrading to release 7.08.

Never ascribe to malice what can be adequately explained by incompetence.

I did nothing more today than fill this in. Bit counting affects the brain.

Mon
Tue
Wed
Thu
Fri
Sat
Sun

Francis reported a problem from France. When a phased out item is used on an order without explicit originating warehouse, not in the header nor on the detail line, the order cannot be released. The use always gets an error stating that there isn’t enough stock even though there is plenty left. The problem is that the program doesn’t use the correct warehouse when testing. Easy to solve but not so easy to find in the first place.

The other problem from France, also reported by Francis is no problem at all. When the used changes the invoice address it doesn’t appear in the DS file as expected. It is only stored there after the order is released. Not all orders are released by simply clicking OK. The example that Peter used to try required four tries.

I finished off the search for the Spanish S3 problem and emailed the conclusions to Inma. I expect to get an answer first thing in the morning.

I had planned to make some appointments today but I didn’t get to it. I only got enough time to add these remarks.

Mon
Tue
Wed
Thu
Fri
Sat
Sun

I have got the phased out items problem in sight now but actually solving it is not simple at all. The OLI sourceing porgram may or may not have run when the order is proposed for releasing and even if it was run lines may have been added afterwards. So it must be run in the releasing routine. The main programming problem is that the availability of the phased out items is done after the normal line processing, so line numbers are not available and the totals are accumulated, if two lines are entered for a certain item the quantities are simply added. This accumulating seems to be explicitly specified so I don’t know if this must be kept or not. An architectural decision is required here.

I called the garage for an maintenance appointment (195.000 KM). That is settled for the 26th so I take that day off. The dentist was not available so I’ll call back tomorrow.

I am about to give up on Mita, I’ll try the Mitac web site tomorrow if I find it. I’ll also check on the Plextor site (PX-12CSe) and the New Media site (BusToaster J9MBTSCSI2 ). If nothing works I can still go in with the slow method and install Win98 from floppies.

Mon
Tue
Wed
Thu
Fri
Sat
Sun

I should have called the dentist for an appointment (preferably on the 26th.) But I was beaten by the clock.

In Germany they want to know the program flow for orders with cash sales type. They don’t have a local warehouse and for cash-sales orders the invoice has to be sent along with the goods. They must thus use a local program to be able to print the invoice in the correct location.

I checked the missing S3 invoices in Spain because I didn’t yet get a mail or phone reaction. The offending orders have been removed from S3 and TH. And the trigger processing has run successfully with processed records removed from TH (only 128 records left) and added to S3 (about 6000 records more than last time). I expect an answer by mail but, as all seems to be OK it may take some time to arrive. With the next problem probably (something like "Thank you about ... but we have a problem now with ... ").

Then Francis called from (France?) with a problem that looks as if they copied the situation from Spain. Only it seems he was using a mix of old and new programs, in the production environment!!. We checked the database and, at first sight everything looks normal. We passed the problem on to Tom to get the correct programs to France so they can try again. I only hope that Francis hasn’t mangled that database. He is used to do such things, mostly he can get back to a correct situation.

And than we had a remark from Germany that there is still some problem with the postings to OFI. Invoices look OK but maybe the posting program hasn’t run.

While I was looking for a direction from which to attack the problem Jan Gerts, from the US, called with a problem concerning memos. Memos entered by TeleSales cannot be viewed in OMSI-3 on the AS/400. This is indeed a problem. The memo is added to the correct files but a field that is required in OMSI-3 is not available in TeleSales

And then there is still the phased out item problem.

And there are just 24h a day.

I prepared the new desk on the attic and I’ll move one of the boxes up there real soon now. The desk is a bit deep now but when I move the 17 inch Yakumo there that ‘problem’ wil be solved.

Mon
Tue
Wed
Thu
Fri
Sat
Sun

The car was frosted over this morning. A little frost wont do the car no harm but as we were preparing the flower garden the will probably some replanting to be done later. The weekend forecast is for the same weather probably until halfway next week.

I just connected some lose ends from yesterday.

We had a strange problem with the server part of the TeleSales application. In the order entry you can request order validation only via a menu option. The order validation is also executed if you (try to) close the order. The validation itself is performed by a program on the AS/400, the only difference between the two methods is a parameter that instructs the program to either stop after validation, returning the result back to the Progress side, or to pass the order on to the Logistics module on the AS/400. When running online the order exists only in a temporal member, with overrides laid and lifted by a CL program. The problem we had was that the online validation went right with the order passing all the tests but subsequent releasing the test on existence of lines fails. Debugging the server side program reveals that the lines are not found although querying, from within the debugger, does see the records. This is a mysterious access path issue. After trying several orders and debugging the actual service routines we still don’t see any error. Logging of and restarting with a new session, and new instances of the server, solves the problem. Weird. we lost about the whole afternoon on this.

If that was not strange enough the stock update comes in message waiting. The stock update program is submitted (via the data queue) when a released order is taken back to hold. The dump and job logs point to a commitment control problem but the error is trapped only two levels after it occurs so the actual error dump is not made. According to Tom this is a masquerading decimal data error.

Between the acts I helped Dimitri out of a problem in Sweden.

I left the office at half past six, that is a work day of almost 14 hours! I did not do much at home.

Mon
Tue
Wed
Thu
Fri
Sat
Sun

I got up rather late.

I got up rather late. While shopping I was looking for a qwerty keyboard but I didn’t find any. The standard keyboad in Belgium is azerty, This has the French layout, with accented characters on the top row, pushing the numeric keys to the shift position, and some other modifications, like the M beside the L and the \ needing the right-alt key. If you type in French that is OK because there you need those accented characters, even in Dutch the layout is not really a problem. Only, I work in a Dutch company and in the Netherlands they use qwerty keyboards so when I get home I have to adapt to a different layout and in the morning I must re adjust again. This way I’ll never learn to touch type.

I missed an appointment with the bank. I have enough money not to worry my and not so much that it bothers me so I tend to forget about it. I enter the bank only about once or twice a year, typically when one of my cards expires. I made an appointment though so I should have gone. I’ll have to apologize.

After washing this noon I mowed the lawn. This is only the second time this year so that went easy and fast because the grass hadn’t grown a lot yet.

Together with Peter I went shopping again for another set of parts for his greenhouse We also transferred the old living room table from the attic to his place for repair, tomorrow we move it up to his house to install Pa on it. Pa is the old 486 PC from my father that I upgraded with a Cyrix P200+ chip and 64MB of RAM.

Evening spent on reading up. The magazines are piling up again.

Mon
Tue
Wed
Thu
Fri
Sat
Sun

The weather forecast (overcast with spells of rain and some sunny breaks) was way off mark. It was dry and sunny, with a few passing cloud formations.

I setup a home page and calendar for use with Netscape 4.51 on Timareen. A web connection must follow but the attic needs to be ready first (not finished, just ready) . And I must get Linux set up as server. If things don’t move fast enough I’ll have to hook up Timareen alone. I think I must aim for August.

Peter has repaired the table. We took it to the back room and assembled it there. It’s much more stable than before. Transferred Pa from his attic to the back room. Pa is a fairly simple computer with no printer or external drives or modems or such and yet it sprouts an incredible birds nest of wires. It took about half an hour just disconnecting cables, moving everything over and reconnecting. Bootup went smooth, without any problem. I did some desktop rearranging with a few tips and explanation because Peter is not really fluent in Windows. He knows enough to keep things going, or even to install new programs (and games) but he doesn’t use a computer because he likes computers but rather because it is useful tool. BTW he is still using the old portable Tosh (286 + 1MB + 20MB) running DOS (DRDOS-6) and WordPerfect (5.1) and Symphony (Lotus). After about 10 years abuse aboard merchant ship it still refuses to die.