Well the programs run a large complex "machine" (keeping it generic). Each piece of the machine has a number of realtime programs that run them, seperate control systems, and they communicate with a central computer system/display.

I've collected all the messages that come from each of the subsystems that communicate with this central display process (by examining the actual C sourcecode of each program used in each machine, because that's where the messages originate from). They're scattered through a dozen independent realtime systems with interchangeable components, etc.

The users of the whole system want to know why some of the messages (often error messages) appear on the display even when there isn't a problem and other times they simply don't know if the messages are important.

Many of the messages have been misclassified, so part of this job would be to analyze the messages, and rank them according to how severe they are.

I may eliminate some of these messages directly in the code.

Some may need to be made more severe.

There are hundreds of possible messages coming from each machine, and the users have no idea what all of them mean--as many are very cryptic.

So part of the job will be making the messages more user friendly.

And I will want to make notes on these items.

Finally, I need a way to report on all the messages of a given severity or by which piece of hardware they originate--probably in a table.

Essentially providing the users of the system with documentation (because they were given none from the developers)...

I guess it gets complicated because the data I've collected may affect the source. the source is where I originally generated the data, and because every message is identified according to its position in the source code, that position could change if someone adds a single line of code to a file with multiple messages in it.

We don't have a lot of DB experts around here... they're mostly engineers with very little experience in software architecture. I'd be in the same boat, but I've picked up most of my "good" habits from my love of Perl. it just kinda makes you think about doing things in a better way.

I appreciate the feedback. I know I sound a bit distracted and scattered--and I admit the vague nature of this is somewhat more of a question of software architecture, than one of Perl--but like I say, the smartest minds I know in computers tend to be here. And Perl just makes things that much easier.

Since you can edit the messages in the C source, I suggest adding a unique but easily distinguished error ID code to each one. For example:

"Something bad happened. (err0r_aaaa)"
"Oh crap - you're hosed. (err0r_aaab)"
"The thingamajig dumped. (err0r_aaac)"
[download]

Then a simple $ grep -rin err0r * in the top-level source directory will result in something like:

some/dir/something.c:42:        dump_err("The thingamajig dumped. (err
+0r_aaac)");
some/thisthing.c:32:      log("Something bad happened. (err0r_aaaa)");
thatthing.c:41:      return "Oh crap - you're hosed. (err0r_aaab)";
[download]

which you can split into path/filename, line#, and error message to update whatever you use to track the error messages.

Bonus, whenever someone receives an error message you can use the (idcode) to determine the exact source of the message, even if different .c files have otherwise identical messages.