Vint,

This could be APAR IC29998 which identifies a problem that
a GPF occurs when the domdsm.log file has some characters
that it did not expect to see.

This problem has been fixed and will be a part of the
next Domino PTF, 1.1.2, which is currently *targeted*
for FTP availability at the end of September.

In the mean time, the work-around for IC29998 is to
rename the domdsm.log file, and rerun the operation.

Thanks,

Del

----------------------------------------------------
Del Hoobler
Del Hoobler
IBM Corporation
hoobler AT us.ibm DOT com

"It's a beautiful day.  Don't let it get away."  -- Bono




                    "Vint A.
                    Maggs"               To:     ADSM-L AT VM.MARIST DOT EDU
                    <vint.maggs@SR       cc:
                    S.GOV>               Subject:     Domino TDP Woes
                    Sent by:
                    "ADSM: Dist
                    Stor Manager"
                    <ADSM-L AT VM DOT MAR
                    IST.EDU>


                    06/13/2001
                    01:44 PM
                    Please respond
                    to "ADSM: Dist
                    Stor Manager"





Hello All,

We have been troubleshooting problems with three of our Domino servers
without luck.  At one point all was well but gradually the backups began
failing.  Nothing has changed on the TSM server side so the thinking is it
must be a client problem.  Various schedules are failing with no apparent
reason. We are running TSM 3.7.3.0 on Solaris 2.7.  The clients are
running NT 4.0, Lotus Domino R5, and Domino TDP 1.0.

Prior to this morning, schedules were failing, though not the same
schedules.  On one server the daily incremental schedule is failing while
on others the hourly archive is failing.  As a work around we could run a
backup from the gui and it worked.

This morning, we broke down what occurs when the scheduled backup runs and
realized that it kicks off the domarc.cmd at the required interval.  All
commands (domarc, dominc, domina) use the same .cfg and .opt file for the
specific node. I executed the domarc.cmd file for SERVER A from a DOS
window and the Dr. Watson appeared.  I then tried just the statement that
runs the job (start /B domdsmc archivelog... excluding the log locations)
and it ran fine. So this backed me into the log files. I changed the log
file name and paths and when executing the domarc.cmd file it ran as
expected.  I duplicated this scenario on SERVER B (which has also been a
problem child) and again it fixed the problem as well. I then went to
SERVER C and did the same for the dominc.cmd that has been failing. Before
making the changes the Dr. Watson appeared. After making the changes and
executing the command in a DOS window it ran without the error on all
three servers.

So with all of that discourse, what gives with the .log files? The Dr
Watson is usually an access violation error.  Is the log file in an open
state from an earlier failure, thus since it can't write it just stops
goes no further?  If this were the case, why does it right some of the
information (i.e. Valid License File....) before the Dr. Watson error
occurs?

Anyone else experience this?

Thanks,
Vint