Conference ilbbak::ibi_focus

    
    Hi there Nick,
    
    Online help in FOCUS V6.1 shows the following:
    
    (FOC 417) ADDITIONAL MEMORY IS NEEDED
    Page file quota may need to be increased for this application.
    
    Your user's PGFLQUOTA of 60000 seems pretty high anyway - is the
    report accessing an exceptionally large database ?? Is the system
    page file too small ??
    
    The text for quite a few FOCUS error messages (especially the Rdb
    related ones) was missing from the FOCUS V5.2.* documentation. This
    seems to have been largely corrected in V6.1.
    
    I hope the report isn't something I wrote -).
    
    Regards,
    
    David
    

    Hi Dave
    
    Not Dave Carse of Crescent/Focus/Fire fame
    
    I dont think it is page file quota. I did an analyse/system and showed
    the free page file quota which was 40000ish. Also the page file has
    plenty of free space. 
    
    Again why does it happen the second time, does it
    not release its virtual memory after each run. Is this a bug in
    Focus I wonder. Have you experienced anything similar.
    
    The Focus version is 5.2.3.
    
    Regards Nick.

    
    >> Not Dave Carse of Crescent/Focus/Fire fame
    
    The very same..!
    
    Does this problem occur every time the user runs the report twice in
    succession ?
    
    I'm not privy to the FOCUS internal code so I can't say if there is a
    bug in FOCUS not releasing virtual memory. However, the recommended
    *process* quotas for running FOCUS are fairly modest, so I'd guess
    that they have this covered. It could be a *system* quota though that
    is being exhausted - FOCUS is pretty good at suppressing VMS messages
    and substituting one of its own that may or may not have bearing on
    the actual error !
    
    Would it be possible to monitor the process running the reports to see
    if it exceeds any *process* quotas ? (You used to have a procedure
    called LOOK.COM to do this - I still have a copy if you haven't.)
    
    If you need to contact me offline you can phone 7782-2834 or send
    mail to FUTURS::CARSED.
    
    Regards  -  David
    

	Plese,
	
	note also #384 in this conference.
	It is relate to the same problem.

	Thanks
	Fabio.                     
    

    No real explanation for what was going on. Changing the procedure
    to look like the following fixed the problem. An initial -RUN
    was added after the FILEDEF.
    
    VMS DELETE COSJUN.DOC;1
    FILEDEF FIN_DATA DISK F2$FIL_RETAIL
    SET LINES = 54
    -RUN
    -*
    TABLE FILE FIN_DATA
    SUM BALANCE
    BY CC_ROLLUP_2   SUB-TOTAL PAGE-BREAK
    BY EFFORT   SUB-TOTAL
    BY ACCOUNT   SUB-TOTAL
    BY BOOKING_CODE
    BY COST_CENTRE
    IF EFFORT EQ '031'  OR '071'  OR '004'  OR '005'  OR '006'  OR '277' OR
    '032'
    IF ACCOUNT GE '006000'
    IF ACCOUNT LE '006999'
    IF FISCAL_MONTH EQ '12'
    HEADING CENTER
    "FACTS2 JUNE REGIONAL COS"
    "------------------------"
    ON TABLE HOLD AS COSJUN FORMAT DOC
    END
    -RUN
    

	Hi

	The problem is still occurring after putting some -RUN 
	in the procedure (where the syntax needs it).

	A further check I did on system is the VIRTUALPAGCNT
	parameter in SYSGEN. Also having it very high, 
	nothing better is happening.
	
	To fix it I had to modify my procedure as follow.

	The error was verified when joining two big relation in 
	a RDB database, so I created a multi-segment file,
	linking the two relations as one.

	E.g. 

	JOIN field1 IN relation1 TO ALL field2 IN relation2 AS MYJOIN
        -RUN 
	TABLE FILE relation1
        ...
	
	is now 

	TABLE FILE oneandtwo 
	...

	file oneandtwo is created by using the two .MAS as one,
	where relation1 is the father and relation2 is the son.

	in .MAS you have 

	FILE=oneandtwo,SUFFIX=RDB

        SEGNAME=relation1
	fields of 1

        SEGNAME=relation2, PARENT=relation1
	fields of 2


	THIS IS NOT THE SOLUTION OF THE PROBLEM, but now my procedure are
	running.                                           
	I hope this can help to solve someone else problems.
	
	Best regards 
	Fabio.
	
	P.S. I think this is also valid for #332 and #384.
    

	The FOC417 error deserve some explanations :

	1	The error is caused by a getvm (get virtual memory) call
		that either fails (insufficient page quota) or returns a
		portion of memory that FOCUS cannot access.

	Remark:	In 5.2.3 some portions of FOCUS can only access 8Meg of
		memory (causing this problem to appear even if the page
		file quota is sufficient) this restriction has been lifted
		in 6.1

Therefore in 5.2.3 the following might cause a FOC417 :

	- application has a large FUSELIB (which gets loaded with FOCUS)
	and leaves only a small amount (below 8Meg) for FOCUS to work
	(I know some applications at Digital have very large FUSELIB
	sometimes as big as FOCUS itself)

	- application loads a large a number of interfaces (dynamically)
	once loaded dynamically an image cannot be released

	- applications opens concurrently a large number of databases
	(and I guess this is what's happening in your case, it might seem
	surprising but I'll explain)

	Finally there is always the possibility of a bug in FOCUS causing
	memory not to be released properly.


Note : When using the RdB Interface FOCUS opens the database based on its
DDNAME, therefore if you have multiple DDNAME pointing to the same database
FOCUS will open the database multiple times (and RdB reserves a large portion
of memory for each database open)

the DDNAME is either the master file name, which need to be filedef to point
to the database, or a parameter in the ACX file

Example if

relation1.acx contains 	seg=seg1,tablename="my_db.relation1"
relation2.acx contains  seg=seg2,tablename="my_db.relation2"

and you filedef my_db disk my_db.rdb

then the file is open only once when you do the join,

however if like I suspect no ddname exist in the acx file
and you use two filedef the database is open twice.
Putting the two relations into one files did solve the problems because only
one filedef was then necessary.