[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

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

2862.0. "MJU V3.0 hangs up" by GANTRY::HULL (Digital Services Delivery - Motown) Mon Jun 14 1993 22:03

We're running A1V3.0-1 and MJU V3.0.  Twice now our MJU runs have hung on 1
user's acct.  This user ('C' in the alphabet range) has about 7000 email
msgs stored in his filecab under non-mail folders (the kind of person you
love to hate!).

Both times now MJU has hung when processing this acct and the current job
had over 19 hours of CPU racked upo since last Friday evening.  The user's
DOCDB.DAT file is about 6000 blocks, but the DAF.DAT is only about 60.

I've looked in our Pre-Test housekeeping run, his acct is ok. The
EMPTY*.LOG* logfile just shows it is processing his acct and that's all
that's ever shown.  No other error msgs.

Suggestions on how to get past this showstopper acct?

	Al
T.RTitleUserPersonal
Name
DateLines
2862.1Run TRUIOSG::MAURICENight rolls in, my dark companionTue Jun 15 1993 09:226
    I'd recommend running TRU on this account with the option set to check
    for body files.
    
    Cheers
    
    Stuart
2862.2Check oa$dds_prime.IOSG::MAURICENight rolls in, my dark companionTue Jun 15 1993 12:417
    Also check the value of oa$dds_prime. There is a problem if this is 2,
    and sending mail to a user would cause a selection list to be
    displayed.
    
    Cheers
    
    Stuart
2862.3Acct in Question tests OKGANTRY::HULLDigital Services Delivery - MotownTue Jun 15 1993 16:0536
Re: .1 - I ran TRU on this 1 acct and it came out clean:

Scanning Drawer [CHU]MAIN at 09:46 AM
------------------------------------------

Number of DOCDB records read:   7284  - 09:46 AM

All requested users processed

No repairs made to personal File Cabinets
-----------------------------------------

Re: .2 - OA$DDS_PRIME = 1 on our system.

Upon closer inspection it isn't even dying during the MJU phase of action,
its dying in the normal EW phase at the beginning.  Here's the user acct
where it hung forever and the acct just previous to it:

Drawer: [CHIRGWIN]MAIN is being processed at 11:20pm
Drawer owned by VMS account: CHIRGWIN Last log-in at: 01-Mar-1991 11:20am
User last logged in more than 4 weeks before last EW run
Drawer: [CHIRGWIN]MAIN emptying wastebasket
Drawer: [CHIRGWIN]MAIN Owner assumed to be inactive.
Drawer: [CHIRGWIN]MAIN reorganized

Drawer: [CHU]MAIN is being processed at 11:20pm
Drawer owned by VMS account: CHU Last log-in at: 31-Mar-1993 08:47pm
User last logged in during 4 week period before last EW run
Drawer: [CHU]MAIN Owner has not logged in recently.

[Hung here over a weekend with over 19 hrs CPU time racked up...]

I need to resolve this soon so we can get a good MJU/EW run and then do an
FCVR run!

	Al
2862.4Already in folder ??UTRTSC::EISINKNo pay, no cure !Tue Jun 15 1993 16:159
    	I've seen this before when MJU was refiling a message or document.
    After investigation it seemed that mju refiled the document but that
    document was already in that particular folder. While it does not
    checked for it the document is still current so it will loop forever.
    
    Put trace on and get the status back. Hope this is the same one
    
    Reported this lonnnnng times ago to assets,
    		regards Rob
2862.5Reorganization problemIOSG::MAURICENight rolls in, my dark companionTue Jun 15 1993 16:2314
    Hi,
    
    Looks as if it's the reorganization that's failing. You can prove this
    by (temporarily) putting the user into a unique department (field in
    profile) and then running EW with the option not to reorganize, and
    just for the specified department. If that works then run the same
    again, this time with reorganization.
    
    The reorganization uses the VMS CONVERT utility which uses temporary
    files. Is disk space a problem?
    
    Cheers
    
    Stuart 
2862.6Got past 2 hurdles - 1 left to goGANTRY::HULLDigital Services Delivery - MotownTue Jun 15 1993 19:4111
Stuart - thanks for the great suggestion.  I ran the EW (w/MJU built in)
with no reorg on just that 1 acct.  It completed ok in 4 minutes elapsed
time.  His acct diskquota was set to max 60000, was at ~47000.  Looking at
the files during the run it's possible that the old DOCDB.DAT (5800 blocks)
plus the new one (3824) plus the DOCDB.TMP (also 3824) might have been just
at the DQ limit.

The EW with Reorg just completed now (I had boosted the Quota to 100K
blocks first).  Now I'll try the EW with Janitor too.

	Al
2862.7he's historyGANTRY::HULLDigital Services Delivery - MotownTue Jun 15 1993 20:5511
It ran thru the MJU part fine since there was apparently no mail at all in
READ or OUTBOX.  This user had 7000+ docs and had refiled every one out of
mail folders to avoid janitor.  He hadn't even logged in here for 3 months.

I am now running a batch job to do SMUNSHARE.SCP against his acct, and will
then back up his acct to tape, and then nuke it forever.  I've been waiting
to do this for 8 months now. 8^)

Thanks for the hints.

	Al