Subj : SOM.IR corruption
To   : Will Honea
From : Mike Luther
Date : Thu Jan 16 2003 12:29 pm

Will ..

Posted in the OS/2 Bugs Usegroup and cross-posted here so the other sharp minds
can maybe give me some insight..

  *******************   Cross Post From Me to ? *********************

Subject says the core question.    What purpose does LTSOMO10.IR serve within
the Lotus SmartSuite application package?

10-25-99   1:37p    119850           0  LTSOMO10.IR

From what I'm being taught, so noted to me the entire SOM.IR operation is
merged together at load time, primarily, to form a 'database' of System Object
Modules.  This if any one of them is 'wrong', bad things can happen to anything
that makes use of the 'database' later on during the uptime of the box.

This one has been reset abruptly, with the only discrete application running on
this box being one of mine which does *NOT* make any use of this, to, for
example:

1-16-03   7:12a        32           0  LTSOMO10.IR

The box, other than the one DOS-VDM I am running .. is totally idle for hours
around this time except for whatever NORMAN 5.4.# is doing on it, as far as I
know.

The anomoly is repetitive twice now in the early morning hours.

One suggestion is to change all the attributes of the SOM.IR files in the mix
to READ ONLY to see what happens.  In that way, it might be possible to
determine what 'application' is doing this unawares to me.   However,since
trying to do this from a running WPS instance produces the immediate notice of
'sharing violation', it looks like the only way to do this will be to REM out
the SOMIR directory line temporarily in CONFIG.SYS to be able to do this for
all of them.

In that a 'sharing violation' does exist when trying this anyway, is this ...
curiously... possibly a way that whatever 'application' is doing this is
resulting in the corrupted file?  Do we, somehow, attempt to write this one
suddenly and get to do enough only to result in the truncated 32 byte file?

Curious mind REALLY wants ot know how this is happening.

It also is then, once happens, co-incident with hard locks to the box,not
POPUPLOG trap data, totally jammed keyboard, and the file then comes up with an
allocation error in the dirty byte CHKDSK32 run to recover the box!

Yet the time for the re-write of this file will be many minutes AHEAD of the
time that the WPS traps and the box actually seems to be jammed...

Thanks


--> Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)