[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| 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 |
715.0. "TRM error - ?Record/bucket locked" by KERNEL::SMITHERSJ (Living on the culinary edge....) Tue May 19 1992 17:48
If its not transfer user, its TRM..........
ALL-IN-1 2.4 unpatched. A customer has run TRM once successfully since
upgrading from 2.3 until now. In the log file, in Phase 1 it says
Scanning User MANAGER's File Cab at 12:37 am
--------------------------------------------
Error reading record from MANAGER'S DOCDB.DAT file
Error of unknown cause, error = ?Record/bucket locked
I've seen a STARS article and various archived notes that suggest it
is the old OA$SITE_LIB_LLV:OA$SM_FCVR.EXE which is the culprit and should
be renamed/deleted leaving the correct version in OA$LIB_SHARE. The file
remaining is dated 30-May-1990. This we have done but still get the problem.
The customer did a SHO DEV/FILES beforehand and the file was not open, nor
were any housekeeping jobs run at the same, or anyone on the system. Did a
EW, FCO just beforehand which worked OK. PT and TRU both failed with the
same error. The A1SUB.log was unhelpful, there is no version limit on the
MGR.DIR but a limit of 3 on the ALLIN1.dir which I got her to up, although
I don't think this is the problem.
PGFLQUO was set to 100,000 which according to my figures is OK (168,000
shared documents x 32 '/, 512. The profile for the manager points to
DISK$ALLIN1.MGR.MGR which is where it is (she says she has run TRM before
with this MGR.MGR and it was OK). No problems with documents or disk
quotaing. Its not a housekeeping job which was left from 2.3 days, it
gets scheduled once only, so its not an old schedule. The sender and the
fetcher are not running and the DOCDB.DAT shows no errors RMS wise.
She points TRM to a generic queue which points to 2 execution queues.
The log file also shows blank default directories but I think they are OK.
It seems as though Phase 1 starts processing at 12.22AM but doesn't
finish until 02.12 AM. In that time each user gets scanned at random
times, ie, not sequentially, I assume this is because of the different
processes being fired off.
Phase 2 starts at 12:39AM - is this normal? I thought Phase 2 would
wait to find out whether it should start running due to Phase 1 errors.
Phase 2 ends at 01:19 before Phase 1. Confused - you will be.
Has anyone any ideas? I'm running out of good questions to ask now.
(:'(
Thanks Julia
CSC
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 715.1 | | IOSG::MAURICE | A few follicles short | Wed May 20 1992 10:53 | 15 |
| Whenever this problem has occurred before it is because the wrong
version of the .exe or command file is being run. Please double check
that there are no conflicts - do a $dir oa$lib:*fcvr* to make sure.
Also check the TRM log - after the title line it announces what version
is being run. This is a more reliable indication that the date of the
.exe file (which I think is the date the customer installed it, though
I'm not sure of this point).
Independently of this problem the customer should want to be patched up
to date.
Cheers
Stuart
|
| 715.2 | | KERNEL::SMITHERSJ | Living on the culinary edge.... | Thu May 28 1992 18:06 | 54 |
| Thanks Stuart
I got the customer to create a new DOCDB.DAT and run TRU on this.
This passed this time whereas on the old DOCDB it had failed. This
made me think there was a corruption somewhere so I got her to run
TRM again. If TRU passed, then Phase 1 of TRM should pass.
Unfortunately not......
It failed with the same error.
>Also check the TRM log - after the title line it announces what version
>is being run. This is a more reliable indication that the date of the
This was 2.4
Below is a dir listing of the customer's oa$lib:*fcvr*. I cannot
verify whether they are the correctly dated files because all our systems
here are patched and it looks like the patches modify the date of
some of the files.
A1$:[ALLIN1.SITE.LIB_BRITISH]
OA$SM_FCVR.OLD 135 10-MAY-1990 (This was the file we
renamed)
A1$:[ALLIN1.LIB_BRITISH]
SM_SKEDSCRIPT_FCVR_MA.SCP;2 16 30-MAY-1990
SM_SKEDSCRIPT_FCVR_PRIV.SCP;2 16 30-MAY-1990
A1$:[ALLIN1.LIB_SHARE]
OA$SM_FCVR.EXE;1 134 30-MAY-1990
OA$SM_FCVR.EXE_DUMMY;1 1 16-MAY-1989
OA$SM_FCVR_PHASE1.EXE 63 5-JAN-1989
OA$SM_FCVR_PHASE2.EXE 35 5-JAN-1989
OA$SM_FCVR_PHASE3.EXE 46 5-JAN-1989
OA$SM_FCVR_PRE_PHASE1.EXE 25 30-MAY-1990
OA$SM_FCVR_PRE_PHASE1_SCHEDULE.COM;5 8 27-MAR-1991
OA$SM_FCVR_PRE_PHASE1_SCHEDULE.SCP;2 5 30-MAY-1990
OA$SM_FCVR_SCHEDULE.COM;3 14 30-MAY-1990
OA$SM_FCVR_SLAVE1.COM;2 8 30-MAY-1990
SMFCVRPH1.EXE;1 66 2-AUG-1988
SMFCVRPH2.EXE;1 39 2-AUG-1988
SMFCVRPH3.EXE;1 40 2-AUG-1988
SMFCVRSCH.COM;1 10 20-FEB-1987
SM_SKEDSCRIPT_FCVR_PRIV.SCP 16 09-JAN-1990
Does TRU use different .exe files to that of TRM - that is
the only thing I can think of? Any wild thoughts on this one?
Thanks
julia
|
| 715.3 | | KERNEL::SMITHERSJ | Living on the culinary edge.... | Fri May 29 1992 17:45 | 3 |
| Alright, how about just any old plain ideas?
|
| 715.4 | | IOSG::MAURICE | A few follicles short | Fri May 29 1992 19:14 | 18 |
| Hi,
1. Can you mail me a copy of the log file please.
2. Can you mail me the contents of OA$LIB:OA$SM_FCVR_SCHEDULE.COM.
3. Can you do a $dif of the two versions of SM_SKEDSCRIPT_FCVR_PRIV.SCP
in OA$LIB.
4. Can you rename old the .EXEs listed in .2 with the exception of
OA$SM_FCVR.EXE and OA$SM_FCVR_PRE_PHASE1.EXE to *.OLD. This will
ensure that the old versions do not get run.
TRU uses the same .EXE as TRM (or should do!).
Cheers
Stuart
|