OLE error on SmartSuite 1.7 for OS/2 - OS2

This is a discussion on OLE error on SmartSuite 1.7 for OS/2 - OS2 ; 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 ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: OLE error on SmartSuite 1.7 for OS/2

  1. OLE error on SmartSuite 1.7 for OS/2

    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

  2. Re: OLE error on SmartSuite 1.7 for OS/2

    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

  3. Re: OLE error on SmartSuite 1.7 for OS/2

    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

  4. Re: OLE error on SmartSuite 1.7 for OS/2

    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

  5. Re: OLE error on SmartSuite 1.7 for OS/2

    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)
    --------------------------------------------------------------------------------------------


  6. Re: OLE error on SmartSuite 1.7 for OS/2

    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
    --


  7. Re: OLE error on SmartSuite 1.7 for OS/2

    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

  8. Re: OLE error on SmartSuite 1.7 for OS/2

    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

  9. Re: OLE error on SmartSuite 1.7 for OS/2

    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




  10. Re: OLE error on SmartSuite 1.7 for OS/2

    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

+ Reply to Thread