[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

3524.0. "POstmaster's DAF eating up disk !" by KAOFS::R_OBAS () Thu Nov 11 1993 20:31

    
     Hello,
    
       Could someone please provide some hints what's causing this problem.
     The Postmaster's DAF.DAT file grows by @500 blocks everytime the 
     Fetcher runs. I re-created the DAF (create/FDL) then cleaned up all
     just about everything from the Postmaster directoryI ran OAMTIMAIL
    (there were 15 messages in A1 mailbox). After the OAMTIMAIL finished
     the Postmaster's DAF grew from 2 blocks to 507 blocks. 
      I did a DUMP/RECORD on the DAF, it's empty. (is it suppose to be
    empty?) There are no NBS files in OA$DATA. The Fetcher runs ok,logfile
    is clean. Overnight it grew from 2 blocks to 25,000 blocks. 
    
     Thanks,
     ricardo
T.RTitleUserPersonal
Name		DateLines
3524.1Try ThisSAHQ::WOLFEJohn Wolfe - (404)-924-6463Thu Nov 11 1993 21:3884
	I forget all the gory details but the problem is due to the handling 
of messages with large distribution lists and an RMS problem w reclaiming the 
space.  We ran into this quite a while ago.

	Try creating the PDAF with an FDL like the following - works for us:

HTH

John

IDENT	" 4-DEC-1991 09:50:32	VAX/VMS ANALYZE/RMS_FILE Utility"

SYSTEM
	SOURCE                  VAX/VMS

FILE
	ALLOCATION              774
	BEST_TRY_CONTIGUOUS     yes
	BUCKET_SIZE             63
	CLUSTER_SIZE            2
	CONTIGUOUS              no
	EXTENSION               63
	FILE_MONITORING         no
	GLOBAL_BUFFER_COUNT     0
	ORGANIZATION            indexed
	PROTECTION              (system:RWED, owner:RWED, group:RE, world:)

RECORD
	BLOCK_SPAN              yes
	CARRIAGE_CONTROL        carriage_return
	FORMAT                  variable
	SIZE                    2000

AREA 0
	ALLOCATION              702
	BEST_TRY_CONTIGUOUS     yes
	BUCKET_SIZE             63
	EXTENSION               63

AREA 1
	ALLOCATION              72
	BEST_TRY_CONTIGUOUS     yes
	BUCKET_SIZE             12
	EXTENSION               0

KEY 0
	CHANGES                 no
	DATA_KEY_COMPRESSION    no
	DATA_RECORD_COMPRESSION no
	DATA_AREA               0
	DATA_FILL               100
	DUPLICATES              no
	INDEX_AREA              1
	INDEX_COMPRESSION       no
	INDEX_FILL              100
	LEVEL1_INDEX_AREA       1
	NAME                    "DAF_KEY"
	NULL_KEY                no
	PROLOG                  3
	SEG0_LENGTH             65
	SEG0_POSITION           0
	TYPE                    string

ANALYSIS_OF_AREA 0
	RECLAIMED_SPACE         0

ANALYSIS_OF_AREA 1
	RECLAIMED_SPACE         0

ANALYSIS_OF_KEY 0
	DATA_FILL               58
	DATA_KEY_COMPRESSION    0
	DATA_RECORD_COMPRESSION 0
	DATA_RECORD_COUNT       10
	DATA_SPACE_OCCUPIED     63
	DEPTH                   1
	INDEX_COMPRESSION       0
	INDEX_FILL              1
	INDEX_SPACE_OCCUPIED    12
	LEVEL1_RECORD_COUNT     1
	MEAN_DATA_LENGTH        1795
	MEAN_INDEX_LENGTH       67
3524.3Discussed before....AIMTEC::WICKS_AU.S.A 2 England 0 - I was there!Thu Nov 11 1993 22:108
    Ricardo,
    
    See also note 1156 - where John's partner in crime Ron (:==:) had a few
    suggestions. I do hope someone has SPRd it.
    
    Regards,
    
    Andrew.D.wicks
3524.4another thought...ANGLIN::HARRISAlost in the jungle of doubtThu Nov 11 1993 22:396
    my customer also had a similar problem, but mine turned out to be a
    user who had an AUTOFORWARD set back to the same account, thus creating
    a loop. the postmaster DAF.DAT would jsut increase rapidly also.
    
    	ann
3524.5Must be tons of SPRs on thisSAHQ::WOLFEJohn Wolfe - (404)-924-6463Thu Nov 11 1993 23:1410
	Re .3

	Andrew - surely there must be millions (well a few anyway) of SPRs
	complaining about the supplied ALL-IN-1 FDL files?  There are few,
	if any, of these that are suitable for decent size systems - Guess how
	long it takes to convert a 1000000 block SDAF with an extent of 100
	blocks?

	John
3524.7Looking good John !KAOFS::R_OBASFri Nov 12 1993 20:3110
    
     After creating a new DAf.dat from the fdl supplied by John, the
    initial size of the new daf was 27 blocks. After the first run of the
    fetcher the DAF size jumped to 168 blocks. I re-run the fetcher and
    sender (about 25 msgs in a1 mailbox), it stayed at 168 blocks. I'll
    monitor it for a couple of days .
    
    Merci'
    ricardo