23 replies to this topic

[Joseph Bove]

Richard,

I certainly don't know that for a fact but we're talking about subtle semantics of the OS/filesystem here and their interaction with ProISAM - what you're doing is in "undefined results" territory for most people.

I know... Sometimes it feels like the majority of the work I do is in the "undefined results" territory!

In all seriousness, that is one of the strengths of this community. I can usually find someone with some experience on most of the ProIV stuff our company attempts.

I appreciate the input.

Regards,

Joseph

[Rob Donovan]

Among other things, I believe that allows multiple "systems" to share a read-only bootstrap across NFS for example.

I was told a while back by ProIV LTD, that if you make all the ProISAM files read-only, then internally when ProIV starts up, it does not create any shared memory segments etc for record locking on any file that only has read only access.

They said that there should be a performance gain if you change your bootstrap files to read only, but I could never prove that.

However, it did reduce the amount of Shared Memory that you needed to allocate for ProIV.

Rob D.

[Joseph Bove]

Peter,

Thanks for that tidbit. I'm at a point where I can't rule anything out. As such I'm hoping for some experience that someone else has had that will resolve this thing.

Regards,

Joseph

[Joseph Bove]

Richard,

Unfortunately, read only and msgf are not a good combo! The ProIV bootstraps must be opening msgf.pro in change mode for every function - whether or not it is appropriate.

I did find one really ugly solution that doesn't require downtime. Copy the application files to a new directory with people on the system. Replace the corrupt msgf with a good one. Change the PROPATH variable so that all new logins reference the new path. As folks log out and new folks log in, the problem with the bad file is generally worked out.

I tested this and it worked fine.

Unfortunately, I don't know if the new clean version of the file will corrupt again or not.

I've asked the client to refresh the msgf.pro file the next time they down the system. Every other trick I could think of was unsuccessful for detaching the corrupt file and putting in a clean one.

I hate to request downtime for the sake of help messages (that no one reads)...

I hope that the issue is resolved after this - but am nervous.

Thanks for the input,

Joseph

[Richard Bassett]

Unfortunately, read only and msgf are not a good combo! The ProIV bootstraps must be opening msgf.pro in change mode for every function - whether or not it is appropriate.

That's very strange/interesting Joseph.. I just tried it again and it works just fine for me on Linux/V4.6/GreenScreen.

Maybe things are different on ProIV+Windows but I am slightly sceptical. OTOH I suppose maybe the multithreaded ProIV server might share open files (handles) between multiple users and the simplictic way of making the file handle reusable for any user/thread would be to insist it's read-write capable. Not very smart though if that's the case.

Edited by Richard Bassett, 06 August 2005 - 10:44 AM.

[Bob Filipiak]

Gentlemen,

I have noted this thread with some interest; because I have encountered a similar situation, years ago. One of our ISAM files was regularly getting clobbered, and I did not have a clue why.

So, I renamed that file to something meaningless, and replaced it with a fresh backup. This trick kept the physical location of the suspect file from changing. Later when the hard disk crashed, I realized that I was given a subtle warning, which I ignored.

A previous post may have hit it on the head, before a hard drive crashes, it often starts to go "flaky" So, I would ask the client how many hours does the drive have on it? Planned maintenance is better than crisis maintenance - but it is so hard to sell to the bean counters siometimes.

HTH

Bob Filipiak

[Rob Donovan]

If you think it might be hard disk errors, have you checked the system messages in Windows?

If you go to the start menu and Right click 'My Computer' and select 'Manage' to view system errors.

Disk errors are normally logged under 'System Tools / Event Viewer / System'.

Also, you were saying that you copy the system to another dir and then change the PROPATH to the new dir and the users start moving over to the new system.

And the corrupt MSGF.pro at some point stops being corrput as the users log out??? Is that true??

Many many years ago (Pre V4 days), there was a bug in the kernel and ProISAM that made ProISAM files 'seem' corrupt when users had a certain combination of other ProISAM files open, the corruption 'fixed' its self as users logged out and closed ProISAM files. This was fixed and I think was probably only relavent to Unix, but it sounds a little like that bug.

Do you get any errors (going to @RFUNCT) within ProIV, trying to read MSGF (or just running screen functions), when the file is corrupt?

Is the file only corrupt, when users are logged in?

HTHs,

Rob D.

[Joseph Bove]

Gents,

Thanks for the input.

Also, you were saying that you copy the system to another dir and then change the PROPATH to the new dir and the users start moving over to the new system.

And the corrupt MSGF.pro at some point stops being corrput as the users log out??? Is that true??

Not quite. I copy the source code over to the new region (with people on the system). I then replace msgf.pro with a good version. Then, I change PROPATH and everything is fine for new logins - and the file appears stable. Given how crappy a solution this was, I didn't want to stress test it - because what would I do if msgf corrupted again?

So instead, I satisified myself that I could use this as a potential solution but asked the client to down the server and put the known good msgf.pro in "real" region.

Do you get any errors (going to @RFUNCT) within ProIV, trying to read MSGF (or just running screen functions), when the file is corrupt?

No @RFUNCT. Instead, just a lack of help and error messages. The help messages are gone and the error messages will only show E054 (for instance).

Is the file only corrupt, when users are logged in?

I don't have enough data yet to answer that. Hopefully simply downing the server and copy the file across will solve the problem... hopefully...

Regards,

Joseph