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