| Title: | *OLD* ALL-IN-1 (tm) Support Conference |
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 |
| Moderator: | IOSG::PYE |
| Created: | Thu Jan 30 1992 |
| Last Modified: | Tue Jan 23 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4343 |
| Total number of notes: | 18308 |
Customer has been running TRM successfully until 3 weeks ago.
PT ran successful before TRM too.
The problem is, TRM which normally takes less than 2 hours to
complete, is still in a CPU-intensive mode after 4 hours !
After the process was terminated with a STOP/ID command, SMLOG*.TMP
are found in the manager's SYS$LOGIN while the log file in OA$LOG
only contains the usual batchjob-startup steps.
SMLOG1.TMP
----------
ALL-IN-1 File Cabinet Verification Repair Program
=================================================
Version 2.4-K603-1
BEgining Phase 1 at 04:05 AM -- scanning users' personal file cabinets
======================================================================
A summary of the repairs made to the personal file cabinets is given
at the end of this phase.
SMLOG2.TMP consisted of users' file cabinets which I'll omit unless
it's required.
SMLOG3.TMP
----------
Begining of Phase 3 at 5:21 AM
==============================
This phase will try to correct the usage counts of shared documents
SDAF record and all references to missing RMS text file deleted
Key = OA$SHARA247:ZUUVD963V.WPC
......
Notice that SMLOG3.TMP doesn't list the SUMMARY OF SHARED DOCUMENT
STATUS IN OA$SHARA
The ALLIN1 manager account has the following quota limit;
WSDEF=1024
WSQUO=2048
WSEXTENT=20480
PGFLOQUO=80000
ENQLM=1000
I have increased the ENQLM from 100 to 1000 but the job still did
not complete within 5 hours yesterday. Anyone has any idea why ?
ching-U
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3232.1 | He doesn't even know what day it is | IOSG::MAURICE | Differently hirsute | Mon Sep 06 1993 09:19 | 12 |
Hi,
I remember there used to be problems if TRM was scheduled with a subset
of SDAFs. Was this the case. Also there was a problem if TRM was
scheduled and instead of leaving the SDAFs blank, they were filled in
but not in order. I can't remember when they were fixed, but I don't
think you have the latest version - and I can't remember what the
latest version for V2.4 is. What a memory!!
Cheers
Stuart
| |||||
| 3232.2 | Yes, SDAFs filled. No, in order | ZPOVC::CHINGYUE | Mon Sep 06 1993 15:36 | 7 | |
Yes and No.
TRM was scheduled with SDAFs entries in the order of OA$SHARA,
OA$SHARB,OA$SHARC and OA$SHARE. Somehow OA$SHARD has never been
open.
What should I do now ? Patch it up to K605 ?
ching-U
| |||||
| 3232.3 | Safe to swap ? | ZPOVC::CHINGYUE | Thu Sep 09 1993 02:38 | 11 | |
It's me again.
My un-patch ALL-IN-1 IOS v2.4 doesn't go into a loop when TRM is
run. It works too with SDAF entries filled up in reverse order.
Is it advisable to replace their OA$SM_FCVR.EXE, dated 2-AUG-1992
with mine dated 30-MAY-1990 ?
Please help.
ching-U
| |||||
| 3232.4 | Things to try | IOSG::MAURICE | Differently hirsute | Thu Sep 09 1993 09:39 | 17 |
Hi,
I wouldn't do that if I were you. Instead I would try and reduce what
TRM is doing in order to get a handle on the area that is causing the
problem. For example I would try the following in turn:
a) Run TRM without bodyfile checking, to see if it completes in that
case.
b) Run TRM in verify mode
c) Run TRM to repair just one DAF (the one the log files indicates it's
looping on.
Cheers
Stuart
| |||||
| 3232.5 | Working... | ZPOVC::CHINGYUE | Tue Oct 05 1993 02:45 | 11 | |
TRM was successful when
1) Run without body checking
2) Repair done only on the smallest SDAF
3) Generic batch queue with 2 execution queues
I've asked customer to enable repair on all 4 SDAF on the next TRM run.
Thanks, Struat.
ching-U
| |||||