Title: Members Experiences

I have only one candidate this issue and that probably should have been a 'From the Coalface' item. Worse I do not know what application is being described nor who sent it. However …

I would be telling you about VisualAge for C++ but when I finally got my hands on a loan copy I discovered that it expected to run under Windows NT 4. I found my copy and a spare hard drive (remember that I do not try software in currently working environments - I've got fed up with having to disentangle the resulting chaos). I then looked for my service patch files, I could not find them. Next I checked the Microsoft site and decided that there was no way that I was going to down load 57 Megabytes over a dial-up connection. I got hold of my son who agreed to send me a copy on CD. He then had problems reading the Microsoft provided CD with the latest SP onto another CD (remember that I have a valid and fully licensed copy of NT4 - actually I have two because I have both a Workstation and a Server version) so getting a CD copy of the SPs was just to save time.

I might also be reporting some experiences with Visual C++ 6.0 but Microsoft seem to be having problems sending me a CD with the latest service patches and it would hardly be fair to comment on the unpatched version would it?

I shall have to chase Inprise for the new release of C++ Builder. If companies would only get their PR/Marketing departments working more efficiently I would be able to spend time telling you about their products instead of chasing them. An I won't tell you about things that I have not tried.

By now time had run out for this issue. I will do my best to get it sorted for the next one.

Now isn't it about time you contributed something instead of relying on others? If you are reading this you must have some experiences of software to share - good, bad or indifferent.

The application comprises of a Visual Basic front end, two continuously looping ProC programs, a Message Management Package used to send telex and faxes to Suppliers. The application is Client Server running on a Windows NT/VMS platform using Oracle as the repository.

Basically what happens is that from the VB front end the users make Nominations to specific Suppliers. These are written to the db with a status of "Ready". One of the ProC programs, that is running continuously, picks up Nominations in a "Ready" status, resets the status to "Queued" does some formatting then passes the Nomination to the Message Management package via an API. The Message Management package is then responsible for sending the Nominations. Details of each Nomination sent are placed in a mailbox. The other, continuously looping, ProC program via an API call retrieves messages placed in the mailbox interprets the return codes and inserts a row into the db. The front end has a timer that periodically checks Queued Nominations against processed Nominations. Nominations that have successfully been sent have their status reset to "null".

Problem; the front-end is intermittently reporting Nominations that have successfully been sent, to be still in a "Queued" status.

Operational solution: close down the front-end application Message Management package, stop the ProC programs. Reset the flags on the db and restart everything again.

Problem solved for one, two, three weeks?

Support/Development solution; check our code, all appeared okay. Contact the Message Management package supplier who we have a support contract for suggestions.

Message Management package Support Team: "Can't be anything wrong with the package, it's been running for 4 years, it must be your code".

Rechecked the code, contacted the Message Management package Support Team again. Grudgingly they conceded the information that a log was maintained of all transactions performed.

Located the Message Management package logs whilst the Support Team were on the phone and asked for some guide lines on how to interpret them. "Don't even try, you won't understand them, just mail them to us".

eMailed the logs to the Message Management Support Team and immediately started to look through the logs. When checking the logs found "write failed to mailbox - mailbox full, cancelling API notifications".

Next day, called the Message Management Support Team.

"Hi, yeah, received the logs, everything is working correctly according to the logs. You need to be running with the debug option on".

Explained to the Message Management Support Team what we had found in the logs.

Slight pause, "We'll get back to you".

The following day, recommendations offered by the Message Management Support Team

Our suggestion, we thought we might just increase the size of the mailbox.

Slight pause, "Yeah, alternatively you could do that".