I've hit an issue where a new installation of the last Lotus Smartsuite 1.7 fot
OS/2 has OLE errors in Lotus 123 whenever a file is attempted closed. The rest
of the tools in the suite work, including WordPro. The error message suggests
that that one should re-install Lotus Smartsuite. That doesn't help.

I've researched a lot at this on the groups. I have verified that the correct
SOM.IR files are all there in this MCP2 latest everything box, that they
compare correctly with other sample such files. I have also looked carefully
at the CONFIG.SYS file at the SOM entries. There is nothing wrong here. As
well, other MCP2 boxes set up the same way with the same CONFIG.SYS files run
fine with it. This includes the three fixes for SmartSuite as well.

One thing I have noticed, is that during a normal boot run, the entries in the
\OS2\ETC\DSOM directory apparently carry the date of last boot run. As if the
database is 'checked' at boot time and so on.

Not on this box! The last time these file dates changed was back in 2005.

Where do I go to start checking for what is going wrong with what I think is
going wrong here, the SOM.IR stuff? I have Theseus on these boxes, but I don't
know what to look for here to compare working and this not working box.

Any help here? Thanks!

--


--> Sleep well; OS2's still awake!

Mike Luther

On 08/22/08 10:09 pm, Mike Luther wrote:
> Not on this box! The last time these file dates changed was back in 2005.
>
> Where do I go to start checking for what is going wrong with what I
> think is going wrong here, the SOM.IR stuff? I have Theseus on these
> boxes, but I don't know what to look for here to compare working and
> this not working box.
>
> Any help here? Thanks!

Is this the same box as the one referenced in "inbound port 23 TCP/IP
loss question?
If so I would consider some subtle hardware failure.
I had a box that crashed in NS4.61 and the sound couldn't handle a
volume change unless the DOS drivers were loaded first. Drove me nuts
because I could not figure it out. (everything else worked) Finally
swapped CPU's and these problems disappeared.
Moral, you can have pretty subtle hardware failures that seem like
software failures.
Dave

Thanks Dave!

Dave Yeo wrote:

> Is this the same box as the one referenced in "inbound port 23 TCP/IP
> loss question?

Interesting and VERY thoughtful help answer here!

Yes it is!

> If so I would consider some subtle hardware failure.
> I had a box that crashed in NS4.61 and the sound couldn't handle a
> volume change unless the DOS drivers were loaded first. Drove me nuts
> because I could not figure it out. (everything else worked) Finally
> swapped CPU's and these problems disappeared.

You know, hadn't even thought of this yet. Both boxes are exactly the same
motherboard, CPU, memory stick brands, NIC chips on the mobos and the exact
same MAC drivers in use. Both are the same SBLive PCI audio card equipped and
work apparently fine with the same Uniaud older drivers. But one is Adaptec
SCSI drive equipped and the other is SATA drive equipped.

Which does open up the wild ride possibility that there are different PCI
matrix response and IRQ and memory port assignments going on in each, scowl.

> Moral, you can have pretty subtle hardware failures that seem like
> software failures.
> Dave

I hadn't thought this way yet. But you sure could be right Dave. If you are
this is going to be worse than an OS/2 aware crippled boy try to be a rodeo
clown for this romp in the ring! Said nervously looking at the bad boy box
case on the ROSE KVM switched bench here ..

--


--> Sleep well; OS2's still awake!

Mike Luther

On 08/23/08 06:21 am, Mike Luther wrote:
> Thanks Dave!
>
> Dave Yeo wrote:
>
>> Is this the same box as the one referenced in "inbound port 23 TCP/IP
>> loss question?
>
> Interesting and VERY thoughtful help answer here!
>
> Yes it is!
>
>> If so I would consider some subtle hardware failure.
>> I had a box that crashed in NS4.61 and the sound couldn't handle a
>> volume change unless the DOS drivers were loaded first. Drove me nuts
>> because I could not figure it out. (everything else worked) Finally
>> swapped CPU's and these problems disappeared.
>
> You know, hadn't even thought of this yet. Both boxes are exactly the
> same motherboard, CPU, memory stick brands, NIC chips on the mobos and
> the exact same MAC drivers in use. Both are the same SBLive PCI audio
> card equipped and work apparently fine with the same Uniaud older
> drivers. But one is Adaptec SCSI drive equipped and the other is SATA
> drive equipped.
>
> Which does open up the wild ride possibility that there are different
> PCI matrix response and IRQ and memory port assignments going on in
> each, scowl.
>
>> Moral, you can have pretty subtle hardware failures that seem like
>> software failures.
>> Dave
>
> I hadn't thought this way yet. But you sure could be right Dave. If you
> are this is going to be worse than an OS/2 aware crippled boy try to be
> a rodeo clown for this romp in the ring! Said nervously looking at the
> bad boy box case on the ROSE KVM switched bench here ..
>

It could be as simple as some oxidation or dust. My box started
spontaneously rebooting the other week. Took it apart, removed all cards
and memory, gave it a good vacuuming and put it back together. Back to
having a stable system.
Of course it could be worse, a slightly wonky power supply or a bad bit
in the memory
Dave

In <48af9b85$0$4033$bbae4d71@news.suddenlink.net>, on 08/23/2008
at 05:09 AM, Mike Luther said:

Hi,

>One thing I have noticed, is that during a normal boot run, the entries
>in the \OS2\ETC\DSOM directory apparently carry the date of last boot
>run. As if the database is 'checked' at boot time and so on.

>Not on this box! The last time these file dates changed was back in
>2005.

This implies that DSOM can not find the directory. SOMDDIR is used to
find \OS\ETC\DSOM. Another possibility is that the daemon is dieing
before it has a chance to access the files.

Are you .IR files OK? Look for any that are unusually small.

Since you have Theseus, you can use System->General system->Open files and
compare the open file list to a working system. Look for files with SOM
in the name.


Steven

--
--------------------------------------------------------------------------------------------
Steven Levine MR2/ICE 3.00.11.16 BETA #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

On Sat, 23 Aug 2008 05:09:29 UTC, Mike Luther
wrote:

> I've hit an issue where a new installation of the last Lotus Smartsuite 1.7 fot
> OS/2 has OLE errors in Lotus 123 whenever a file is attempted closed. The rest
> of the tools in the suite work, including WordPro. The error message suggests
> that that one should re-install Lotus Smartsuite. That doesn't help.
>
> I've researched a lot at this on the groups. I have verified that the correct
> SOM.IR files are all there in this MCP2 latest everything box, that they
> compare correctly with other sample such files. I have also looked carefully
> at the CONFIG.SYS file at the SOM entries. There is nothing wrong here. As
> well, other MCP2 boxes set up the same way with the same CONFIG.SYS files run
> fine with it. This includes the three fixes for SmartSuite as well.
>
> One thing I have noticed, is that during a normal boot run, the entries in the
> \OS2\ETC\DSOM directory apparently carry the date of last boot run. As if the
> database is 'checked' at boot time and so on.
>
> Not on this box! The last time these file dates changed was back in 2005.
>
> Where do I go to start checking for what is going wrong with what I think is
> going wrong here, the SOM.IR stuff? I have Theseus on these boxes, but I don't
> know what to look for here to compare working and this not working box.
>
> Any help here? Thanks!
>

If this is a hardware problem, I would start with memory. The easiest
is to swap if you can. Also Linux has a neat little bootable CD that
has MEMTEST on it as well as many other utilities. This little
program has picked out many a bad memory bit from the used sticks I
buy at swapmeets.

www.sysresccd.org

Hang in there!
Paul
--

Aha !

Steven Levine wrote:

>> Not on this box! The last time these file dates changed was back in
>> 2005.

> This implies that DSOM can not find the directory. SOMDDIR is used to
> find \OS\ETC\DSOM. Another possibility is that the daemon is dieing
> before it has a chance to access the files.

I think I've learned more from you!

> Are you .IR files OK? Look for any that are unusually small.>
> Since you have Theseus, you can use System->General system->Open files and
> compare the open file list to a working system. Look for files with SOM
> in the name.

I'm away from the bad boy box at the moment. But on a system where SmartSuite
works fine, I did some research with Theseus. A freshly booted system with
even the Rexx lib additions to the SOM.IR system has no reference to the .IR
files after a plain boot run.

But as soon as you boot up Lotus 123, then go back at Theseus, down at the
bottom of the boot run, there are the whole pile of .IR files and DLL's which
seem to be associated with this! As well, the instant you open up Lotus 123
this way, that is when the date and time for the DSOM files in the
\OS2\ETC\DSOM directory change to the data this was done.

OK, for years now, as a 'fix' for stopping Lotus Smart Suite from corrupting
the SOM.IR files, I've been opening Lotus 123 immediately after boot up to stop
corruption of them, which does lead to trashing the SOM.IR files! That's even
been acknowledged by Lotus as happening back when all this was of research with
the official Lotus crew as well as on Testcase with IBM! As best I understand
about the work, somehow SmartSuite was opening the SOM.IR files for WRITE
permission, according to what I found back then, together with help from Will
Honea and Will Hartzell at this. Something us outsiders thought was totally
wrong as these files, so coached to me, are database files that should never be
re-written post installation of whatever version of an application needs.

The corruption I saw here was related to child process calls of WORDPRO if one
had not opened up Lotus 123 before they were made. As I understand this, Lotus
123 has the most 'invasive' SOM.IR interface for the suite. It will report OLE
errors from corrupted SOM.IR operations immediately, thus using it for checking
and coordinating SOM.IR operations is the best way to guarantee things are fine
with the DSOM database if SmartSuite is installed.

And this is why all my other boxes 'seemed' to have the date/time for the DSOM
database file apparently the same as the boot up for a box, at first glance.
AHA! Insight!


I'd already checked that the complete SOM.IR files between a working system and
the non-working system apparently are the same size and release date. But I've
not tried to tool up for a GFC on them to check them byte for byte. With work
I can do this if it gets this far.

When I get to where I can dig into this tomorrow, what I need to do is see if
the bad box installation even has any of this SOM.IR file coordination visible
on Theseus on it at all. I have checked that the CONFIG.SYS files for a good
and this bad box have, as far as I knew at the time, the proper lines in the
bad box configuration. But I wonder now, is there an order for the path names
to these files which has to be ahead of something in a CONFIG.SYS file in order
for all this to work? I do recall that the placement of all this in the bad
box isn't at all what I recall seeing in the good box I was using for
comparison. The path name lines in CONFIG.SYS were way down near the bottom of
the file on the bad box and are way up near the top of it on this working unit.

I think I did check carefully to see that the path name direction line in the
CONFIG.SYS box was correct, as coached by the Google search with Paul's advice
long ago to someone who had similar problems with this. I'll report back what
I find here as soon as I have time to dig into this trench more deeply.

Thanks Steve!

--


--> Sleep well; OS2's still awake!

Mike Luther

Solved! Hope the process will help others!

Steven Levine wrote:
> In <48af9b85$0$4033$bbae4d71@news.suddenlink.net>, on 08/23/2008
> at 05:09 AM, Mike Luther said:
>
> Hi,
>
>> One thing I have noticed, is that during a normal boot run, the entries
>> in the \OS2\ETC\DSOM directory apparently carry the date of last boot
>> run. As if the database is 'checked' at boot time and so on.
>
>> Not on this box! The last time these file dates changed was back in
>> 2005.
>
> This implies that DSOM can not find the directory. SOMDDIR is used to
> find \OS\ETC\DSOM. Another possibility is that the daemon is dieing
> before it has a chance to access the files.

Directory citations are correct. Dead daemon, I think so, but why is really
interesting. Read on.

> Are you .IR files OK? Look for any that are unusually small.

All the .IR files are not only correct, but I actually ran a GFC compare on
them between the good and bad box. Perfect match!

> Since you have Theseus, you can use System->General system->Open files and
> compare the open file list to a working system. Look for files with SOM
> in the name.
>
>
> Steven
>

Done and couldn't see anything possible wrong, except for one of the DSOM files
in \OS2\ETC\DSOM itself which as originally noted had a 'zero length'. Recall
that these are not installed files. As far as I know. They are resultant
database information files which the SOM process packages based on what the
operating system and SOM related applications provide for these data files.
And recall also that the SOM.IR files per what Will Honea and Will Hartzel
counseled me are only supposed to be application install time data files, not
subject to open for write gambits by the applications, but which were being
opened that way by SmartSuite at least earlier on.

Studying this very hard in Theseus using your guidelines, I noticed that even
on boot-up the bad box file and DLL mix was different that on a good box of the
same incantation. Duhhh ..

4-23-05 10:35a 0 0 SOMDIMPL.DAT

Why? Maybe the SOM daemon can't even read a zero length file to even write it
and that is another bug not known? Hmmmmmmm .....

OK, I uninstalled the whole SmartSuite application from the original C:\
directory on the bad box and then INSTALLED it FRESH on drive D:\ where I tend
to put applications on my 'normal' boxes. Blam, same error fresh install. And
surprise! No change in any of the DSOM dates at all, post install!

Unimaint showed no errors in the OS/2 INI files. But wait! Ran CHECKINI on
this box. It is FULL of errors UNIMAINT didn't catch! Most interesting of
all is an error for of all things ODwps that is a SOM oriented original program
dating back to OpenDoc pre-MCP1/2 that is no longer or .. was never .. on this
box!

Even CHECKINI can't clean this one up, it looks like on this box. So I loaded
UNIMAINT and forced the removal of it with the expected re-write to the Desktop
and restart. Still no dice on Lotus 123, same OLE error.

OK .. raw sewage gamble. I backed up the DSOM files on the bad box. I then
copied a working set of good ones directly into the OS2\ETC\DSOM directory. I
rebooted the box.

POOF! Perfectly working Lotus SmartSuite and Lotus 123!!!

More important, that first clean SmartSuite open morphed that same
file to the current date and time of the SmartSuite 123 start as
well as the same date and time stuff on all the other DSOM files!

OK, how does this happen? Looking back at my professional time logs, I noticed
that there was a huge mess at this medical facility back in 2005 over things
that had gone wrong with people trying to use SmartSuite 1.5(6) directly over
the facility network trying to edit and work with 123 data files directly on
the LAN server of all things! Including what I found were apparently more than
one workstation person trying to munch what appeared to be the same file at the
same time over PEERLAN. Then when lockups would happen, they just punched off
the AC power switch on the boxes which hard locked, and let them re-start.

Now I already know as to SmartSuite, the SOM.IR files could get corrupted
because of defects in at least the older SmartSuite code. But I never knew
until this 20-odd hour long research run, that if you ever, in the process,
produced a ZERO LENGTH DSOM file, that the SOM daemon might not ever be able to
UPDATE the SOM process even from boot up time!

I think I've found more of the error on this OLE crash deal
others and IBM Lotus and the Austin OS/2 crew have probed.
If you ever have a zero length DSOM file, you'd better have
at least a reasonable good collection of these files as
well as the SOM.IR files to use for a replacement.

Either that or start all over and install OS/2 fresh and all
the applications.

I now have a working good copy of the DSOM files on the box
and I guarantee you I'll add those to the archive copies of
all the SOM.IR files on any given box I keep for this reason.

If you or anyone else here know any other easier way to handle this, PLEASE let
us all know. As well, there may be a possibility that the 'fix' for this open
for write access corruption deal has been taken care of in one of the total of
three official IBM fixes for SmartSuite even 1.7 now.

I don't know if, for real, that has been taken care of. I've avoided all of
this mess since I discovered it by simply booting up and first running
SmartSuite Lotus 123 right after boot. I've never ever seen any of this on any
box we've done this with ever since this showed up back in the 2004-2005 time
line. I still suggest this to all my friends out there that have SSuite.

Thanks Steve for your help and direction. It's been a long, long pig trail
this week. But 'e's in the oven roasting now!





--


--> Sleep well; OS2's still awake!

Mike Luther

Hi,

if you have the OS/2 toolkit installed you can use "pregimpl.exe" to have a
look at the implementation repository (that is what is behind the stuff that
you find in subdirectory \OS2\ETC\DSOM).
If "pregimpl.exe" fails you know something is wrong with your DSOM setup (as
Steve suggests, you need to have SOMDDIR set up correctly along with a
couple of other things like a working SOMIR environment variable including
all listed .IR files being OK).
Run "pregimpl.exe" on the box that is OK and on the box that fails and
compare. "pregimpl.exe" is fairly self explaining.

There is another tool in the OS/2 toolkit: "irdump.exe". You can check each
single .IR file listed in the SOMIR variable doing this from a commandline:

set SOMIR=c:\OS2\SOM.IR /* or whatever .IR file you want to check */
irdump.exe

you can of course pipe the output into a file:
irdump.exe > dump.txt

Just another tip: if you have the toolkit installed, make sure that in
LIBPATH you have the toolkit paths (at least the one containing som.dll and
somd.dll) before \OS2\DLL. Then you will use the som.dll,somd.dll etc. from
the OS/2 toolkit which is newer than what comes with eCS.


Lars

"Mike Luther" schrieb im Newsbeitrag
news:48b17dac$0$4047$bbae4d71@news.suddenlink.net. ..
> Aha !
>
> Steven Levine wrote:
>
>>> Not on this box! The last time these file dates changed was back in
>>> 2005.
>
>> This implies that DSOM can not find the directory. SOMDDIR is used to
>> find \OS\ETC\DSOM. Another possibility is that the daemon is dieing
>> before it has a chance to access the files.
>
> I think I've learned more from you!
>
>> Are you .IR files OK? Look for any that are unusually small.>
>> Since you have Theseus, you can use System->General system->Open files
>> and
>> compare the open file list to a working system. Look for files with SOM
>> in the name.
>
> I'm away from the bad boy box at the moment. But on a system where
> SmartSuite works fine, I did some research with Theseus. A freshly booted
> system with even the Rexx lib additions to the SOM.IR system has no
> reference to the .IR files after a plain boot run.
>
> But as soon as you boot up Lotus 123, then go back at Theseus, down at the
> bottom of the boot run, there are the whole pile of .IR files and DLL's
> which seem to be associated with this! As well, the instant you open up
> Lotus 123 this way, that is when the date and time for the DSOM files in
> the
> \OS2\ETC\DSOM directory change to the data this was done.
>
> OK, for years now, as a 'fix' for stopping Lotus Smart Suite from
> corrupting the SOM.IR files, I've been opening Lotus 123 immediately after
> boot up to stop corruption of them, which does lead to trashing the SOM.IR
> files! That's even been acknowledged by Lotus as happening back when all
> this was of research with the official Lotus crew as well as on Testcase
> with IBM! As best I understand about the work, somehow SmartSuite was
> opening the SOM.IR files for WRITE permission, according to what I found
> back then, together with help from Will Honea and Will Hartzell at this.
> Something us outsiders thought was totally wrong as these files, so
> coached to me, are database files that should never be re-written post
> installation of whatever version of an application needs.
>
> The corruption I saw here was related to child process calls of WORDPRO if
> one had not opened up Lotus 123 before they were made. As I understand
> this, Lotus 123 has the most 'invasive' SOM.IR interface for the suite.
> It will report OLE errors from corrupted SOM.IR operations immediately,
> thus using it for checking and coordinating SOM.IR operations is the best
> way to guarantee things are fine with the DSOM database if SmartSuite is
> installed.
>
> And this is why all my other boxes 'seemed' to have the date/time for the
> DSOM database file apparently the same as the boot up for a box, at first
> glance. AHA! Insight!
>
>
> I'd already checked that the complete SOM.IR files between a working
> system and the non-working system apparently are the same size and release
> date. But I've not tried to tool up for a GFC on them to check them byte
> for byte. With work I can do this if it gets this far.
>
> When I get to where I can dig into this tomorrow, what I need to do is see
> if the bad box installation even has any of this SOM.IR file coordination
> visible on Theseus on it at all. I have checked that the CONFIG.SYS files
> for a good and this bad box have, as far as I knew at the time, the proper
> lines in the bad box configuration. But I wonder now, is there an order
> for the path names to these files which has to be ahead of something in a
> CONFIG.SYS file in order for all this to work? I do recall that the
> placement of all this in the bad box isn't at all what I recall seeing in
> the good box I was using for comparison. The path name lines in
> CONFIG.SYS were way down near the bottom of the file on the bad box and
> are way up near the top of it on this working unit.
>
> I think I did check carefully to see that the path name direction line in
> the CONFIG.SYS box was correct, as coached by the Google search with
> Paul's advice long ago to someone who had similar problems with this.
> I'll report back what I find here as soon as I have time to dig into this
> trench more deeply.
>
> Thanks Steve!
>
> --
>
>
> --> Sleep well; OS2's still awake!
>
> Mike Luther

Aha! I see an arched doorway ahead!

Lars Erdmann wrote:
> Hi,
>
> if you have the OS/2 toolkit installed you can use "pregimpl.exe" to have a
> look at the implementation repository (that is what is behind the stuff that
> you find in subdirectory \OS2\ETC\DSOM).
> If "pregimpl.exe" fails you know something is wrong with your DSOM setup (as
> Steve suggests, you need to have SOMDDIR set up correctly along with a
> couple of other things like a working SOMIR environment variable including
> all listed .IR files being OK).
> Run "pregimpl.exe" on the box that is OK and on the box that fails and
> compare. "pregimpl.exe" is fairly self explaining.
>
> There is another tool in the OS/2 toolkit: "irdump.exe". You can check each
> single .IR file listed in the SOMIR variable doing this from a commandline:
>
> set SOMIR=c:\OS2\SOM.IR /* or whatever .IR file you want to check */
> irdump.exe
>
> you can of course pipe the output into a file:
> irdump.exe > dump.txt
>
> Just another tip: if you have the toolkit installed, make sure that in
> LIBPATH you have the toolkit paths (at least the one containing som.dll and
> somd.dll) before \OS2\DLL. Then you will use the som.dll,somd.dll etc. from
> the OS/2 toolkit which is newer than what comes with eCS.
>
>
> Lars

Yes, I do have the toolkit installed on I think three boxes here. But it's not
installed on the ex-bad-boy box. With an old Western Digital SCSI hard drive
in the bad-boy box, it's site boss chose to approve my cloning it into a new
Seagate SCSI drive which will likely be in here Wednesday of next week.
Between now and then I'm going to try to walk through the arch of your doorway
into a new area to learn in Lars. I should have tried to learn what's in the
toolkit before, but didn't. My bad. Gotta start somewhere, so I guess here we
go. Thank you!

--


--> Sleep well; OS2's still awake!

Mike Luther