Well, I still don't understand much about System Object Models even after reading at it ... err ... by force, not choice, gloom.

And I didn't think that it had anything to do with RUNNING applications sort of, until I wound up with a Lotus Smart Suite not even being able to open up a Lotus 123 file without, "Unexplained OLE Error..." But, lo, it can relate to this. After hours of research I stumble onto both the Lotus Assistance web site and Usegroup remarks which say my exact syndrome looks like empty extra space marks in the SET SOMIR= path string .. or ..

"An .IR file described in that path with 32 bytes in it!"

Duhh ... what's that?

As well this helpful soul notes that the SOM.IR files are really subject to corruption, we don't know how, but if you are smart, you'll keep a backup of them to use for restore purposes.

Duhh ... so sure enough, just ahead of the LOTUS .IR directories, is my WATCOM V11 C/C++ compiler citation for WATCOM\SOM\ETC and you know, there are four .IR
files in it. One of them, SOM.IR has only 32 bytes in size and it is totally empty. Gee, that's interesting! I wondered, what might this be like from months ago on my tape backups?

Uhhh... SOM.IR there has 349,280 bytes and is dated in 1997,
The one here had an August date ... and 32 bytes?

Hi ho, hi ho, it's off to tape we go! Not so fast dog! Turns out that file is
locked and I can't replace it from tape! Hmmm .. OK, REM out the line for SET SOMIR in CONFIG.SYS and try that. Sure enough, restore works, but not without a complaint from BA/2 about resetting permissions or something as well. But this time, in this case, after replacing JUST THAT ONE WATCOM .IR file that appeared bad,

VOILA! Lotus 123 is working again!

Now .. how can that be that Smart Suite can't function without
a prior SOM.IR being right for an application that has NOTHING
to do with Lotus Smart Suite???

Oh well, back to work.

****************** Time passes through New Year! ******************

Not so fast puppy. I noticed that Watcom has released their 'final' public release of Watcom V11C late in December. I've already updated those files back
about August, but we might as well get these latest ones on January 10,2003, and zip 'em into the box. Well, two of them won't erase in UNZIP unless you disable the RUN BATSERV.EXE and RUN NMPBIND.EXE in CONFIG.SYS. After that the fix release versions will go into the update.

But ... suddenly, now, again, Lotus 123 is failing to load! And this time I discover that there are MORE botched .IR files in this mix that were NOT botched prior to the attempted update of Watcom!!

I discover in C:\OS2\ETC that REXX.IR and WPSC.IR are now 32 bytes, with the January 10, 2003, date and time I did the UNZIP for the Watcome update...


Errr.... this ain't good. In all I wound up restoring from tape a total of I thing four .IR files bad, plus Smart Suite would still not work this time. What
to do? Re-install Smart Suite! Sounds like Windows, no?

Answer ... Well, first try to use the provided Smart Suite Uninstall Icon. Well, that leaves the directories still on the disk! Plus, it seems, that there are still all kinds of things in the .INI file left behing as well from this neat provided Icon of Faith! So, instead, use Unimaint to remove all traces of SmartSuite from the system and surprise!

Unimaint balks as well on removing the Smart Suite .IR files too!

Back to the disable SET SOMIR= in CONFIG.SYS to complete the job and then re-instate it as well. Hmmmm, puppy is looking at how to crawl under the fence
in the back yard by this time.

OK, from a re-install clean, plus update to this and that, Smart Suite is back working again. But strangely, the .IR files are, in some cases,different than they were in the tape backups which SHOULD have been OK as Smart Suite was working fine, I think, then ???

Scratching head ???

Hmpf .. Off reading "Client Server Programming With OS/2 2.0", Part VI trying to learn about SOM. But you know, there were all kinds of corruption issues in
the .IR files from dates that were really should never have been involved in this. Then, suddenly, I realized that when I first 'updated' Watcom V11 with that initial test release of the public code, it was ... err ... August 5th ...
???

Aha, insight ?

What is the rule of thumb on all this SOM madness? If this kind of thing can wreak an application collection like this, what do we really need to do to check this? Does one really have to make a special trip around the SOM.IR directories to see what REALLY has been pranged, every so whatever times?

Just how does this SOM thing work anyway and what ARE the caveates?

Inquiring mind wants to know.

Thanks.

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

Mike @ 1:117/3001

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

Mike Luther wrote to All on 01/13

What is the rule of thumb on all this SOM madness? If this
kind of thing can wreak an application collection like
this, what do we really need to do to check this? Does one
really have to make a special trip around the SOM.IR
directories to see what REALLY has been pranged, every so
whatever times?

Just how does this SOM thing work anyway and what ARE the
caveates?

Mike, the rule that works for me is that NOTHING supercedes the Warp
system directories. VACPP 3 had a bad habit of back leveling SOM that
would kinda sneak up and bite when you least expected it. I don't know
what SOM directories are used by Lotus - don't run the critter - but
keeping everything subservient to the original system ir's works for
me.

WTF! Just looked at config.sys and what a mess on the set somir= line
- how the heck is this thing running, anyway? Anyway, reset it and
I'll see what happens - maybe that where some of the funnies are coming
from lately.

FYI, the MCP1 with CP03 has the following:

Directory of E:\OS2\ETC

9-06-00 12:42p 66,058 0 a--- REXX.IR
6-30-99 4:28p 496,503 0 a--- SOM.IR
11-14-00 6:06p 60,855 0 a--- WPDSERV.IR
11-14-00 5:53p 274,823 0 a--- WPSH.IR
4 file(s) 898,239 bytes used

and each in referenced with an explicit path in config.sys.


Will Honea <whonea@codenet.net>

___
■ KWQ/2 1.2i ■ I'm an OS/2 developer...I don't NEED a life!

--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

Will ..

WTF! Just looked at config.sys and what a mess on the set somir= line
- how the heck is this thing running, anyway? Anyway, reset it and
I'll see what happens - maybe that where some of the funnies are coming from lately.

Oh, if what I've found is correct, it gets REAL worse!

Check your Email. I've copied off another of my tons of log lines time trace analysis deals which show what I think is very suspicious evidence that the SOM.IR files are getting corrupted in a very different way than we thought.

Again, what I'm finding is that Z! ain't responsible at all for the lockups. In fact the file and disk corruption is taking place, per my log showings, even
HOURS before the final lock up hits. After the WPS crashes and the system clock freezes on the WPS, the box is actually running in the background for a long time yet mashing even more damage here and there. Z! and a constant bashing of TCP/IP data simply exacerbates the final product of the brewer's art!

I'd like for you to think about what I posted as well as the other parties involved before we go ranting and raving here. I could be very wrong.

Thanks.

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

Mike @ 1:117/3001




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

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)

Added information..

Of two LTSOMO10.IR corruptions which have taken place, I now know from further research that one of the corruptions took place at exactly the time the following files were written in the C:\OS2\ETC\DSOM directory:

**************** Possible relevance! ***************

The C:\OS2\ETC\DSOM directory has in it:

1-15-03 6:22p 6440 0 SOMDCLS.DAT
1-15-03 6:22p 6904 0 SOMDCLS.TOC
1-15-03 6:22p 2024 0 SOMDIMPL.DAT
1-15-03 6:22p 116 0 SOMDIMPL.TOC

Whatever was involved in writing these files was active at
the same time

LTSOMO10 IR 32 1-15-03 6:22a <******** BAD!

was corrupted!

Now .. what writes these, when and why?


Thanks!

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

Mike @ 1:117/3001

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

OK Will and anyone else reading along.

I now know what RE-WRITES the files in:

[C:\os2\etc\dsom]dir

8-09-96 2:49a 6384 0 SOMDCLS.DAT
8-09-96 2:49a 6844 0 SOMDCLS.TOC
8-09-96 2:49a 1012 0 SOMDIMPL.DAT
8-09-96 2:49a 60 0 SOMDIMPL.TOC

Every time you load a new spreadsheet in Lotus 123 for OS/2 at least for version 1.51, you rewrite every one of these files...

Further, I've found out that if you set the .IR files to Read Only, Lotus SmartSuite won't load 123 files at all and produces that same, "Unexpected OLE Error", with no number from which to refer!

My guess this is a named pipe dream game since the SOM Daemon has them open for
whatever as read-write, per Steve's comments too!

Thus if, for whatever reason, Lotus SmartSuite has a file like a 123 spread sheet open and the box takes a hit big time .. who knows what evil will be slammed onto the whole SOM mess if the box is really blammed!

And if HPFS lazy write cache is involved in this mess too ...

oiyveigh .. what a fiddle fest on the roof!

No?

Just thinking about SOM and Windows and so on. Is this a good example of why WINDOWS code operated boxes are so fragile if it's all written like this?

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

Mike @ 1:117/3001

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

Hi Mike,

Replying to a message of Mike Luther to Will Honea:

[snip]

LTSOMO10 IR 32 1-15-03 6:22a <******** BAD!

was corrupted!

Now .. what writes these, when and why?

The file extension .IR stands for Interface Repository. Such a file contains the SOM interfaces available with the object classes defined by the application. In the case of Lotus Smart Suite (WordPro, 1-2-3, etc.) the object
classes are those for the various document types. The interfaces published are those for opening the application for a given document, dragging and dropping documents (especially when the target of the drop is a printer) and various other activities.

The common denominator in all this is also the Object Request Broker (ORB) used
by OS/2: the WorkPlace Shell. Moreover, it is the WPS that locks the various .IR files when it starts. The physical reads and writes of these files are managed by the WPS too, and they are initiated by user activity in the shell and by SOM applications issuing object messages to the ORB.

The file corruption can be caused by bugs in the ORB or by bugs in the SOM applications. Since your problems usually end up with a trashed Lotus file, the
likeliest candidate is Lotus Smart Suite. I am running V1.5.1 of SS and it has yet to trash its IR, but earlier versions were quite annoying in the frequency with which they trashed their SOM interface repository.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)