There may be a bug in the release of UniVerse that was not in the previous
release.  This may be not causing the sting to be cleared and the process is
just concaternating.   This could also be something looping and writing to
the como file or the spooler.  I would debug the program that is causing the
problem.

Regards

David Jordan

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ang Suan Yong
Sent: Tuesday, 29 June 2004 2:08 PM
To: [EMAIL PROTECTED]
Subject: RE: [U2] Available Memory Exceeded


Dear All,

        Is true that this program is building a huge string. However we
didint face in our old system , ie Universe 9.6 on Sun Solaris 
        
        We have just migrate to Sunfire 6800 (having 16g of RAM) and the
Database using Universe 10.0.8 , Sun Solaris 9, the UVCONFIG is using same
as the old system. /tmp file is ufs file system still 15g available and
during the program run is no much users access to the system and the server
is not heavy usage during as well as no much Record Locks at that point  

        Wondering is the new version of Universe 10 having certain kind of
control on memory/buffer ?



Thanks and Regards

Below is the setting of the uvconfig


        Current tunable parameter settings:
        MFILES         =   56
        T30FILE        =   400
        OPENCHK        =   1
        WIDE0          =   0x3dc00000
        UVSPOOL        =   /maa04/uvspool
        UVTEMP         =   /tmp
        SCRMIN         =   3
        SCRMAX         =   5
        SCRSIZE        =   512
        QDEPTH         =   16
        HISTSTK        =   99
        QSRUNSZ        =   2000
        QSBRNCH        =   4
        QSDEPTH        =   8
        QSMXKEY        =   32
        TXMODE         =   0
        LOGBLSZ        =   512
        LOGBLNUM       =   8
        LOGSYCNT       =   0
        LOGSYINT       =   0
        TXMEM          =   32
        OPTMEM         =   64
        SELBUF         =   4
        ULIMIT         =   128000
        FSEMNUM        =   23
        GSEMNUM        =   97
        PSEMNUM        =   64
        FLTABSZ        =   11
        GLTABSZ        =   150
        RLTABSZ        =   150
        RLOWNER        =   300
        PAKTIME        =   300
        NETTIME        =   5
        QBREAK         =   1
        VDIVDEF        =   1
        UVSYNC         =   1
        BLKMAX         =   16384
        PICKNULL       =   0
        SYNCALOC       =   1
        MAXRLOCK       =   130
        ISOMODE        =   1
        PKRJUST        =   0
        PROCACMD       =   0
        PROCRCMD       =   0
        PROCPRMT       =   MODFPTRS       =   1
        THDR512        =   0
        UDRMODE        =   0
        UDRBLKS        =   0
        MAXERRLOGENT   =   100
        JOINBUF        =   4095
        64BIT_FILES    =   1
        TSTIMEOUT      =   60
        PIOPENDEFAULT  =   0
        MAXKEYSIZE     =   255
        SMISDATA       =   0
        EXACTNUMERIC   =   15
        MALLOCTRACING  =   0
        CENTURYPIVOT   =   1930
        SPINTRIES      =   0
        SPINSLEEP      =   10000
        CONVERT_EURO   =   0
         SYSTEM_EURO    =   164
        TERM_EURO      =   164
        SQLNULL        =   128
        UVNET_CONNECT        =   0
        allowmarks        =   0



> -----Original Message-----
> From: Clifton Oliver [SMTP:[EMAIL PROTECTED]
> Sent: Tuesday, 29 June, 2004 9:37 AM
> To:   [EMAIL PROTECTED]
> Subject:      Re: [U2] Available Memory Exceeded
> 
> Unreleased locks would not, however, cause "available memory exceeded"
> messages. What you get is <mumble mumble memory failing> something 
> along the lines of "lock threshold reached." Available memory exceeded 
> usually, in my experience, is caused by a program building a huge 
> string, like a dynamic array.
> 
> --
> 
> Regards,
> 
> Clif
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> W. Clifton Oliver, CCP
> CLIFTON OLIVER & ASSOCIATES
> Tel: +1 619 460 5678    Web: www.oliver.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> On Jun 28, 2004, at 11:26, Dan Fitzgerald wrote:
> 
> >>> Recently we encounter a process of running  900,000
> >> records and every internal of around 200,0000 record the process
> >> terminated
> >> and prompt this error message<<
> >
> > Given just this much information, I'd start by looking at locks 
> > being
> > held and not released by this process. How many entries when you do a 
> > "LIST.READU EVERY" during the run? If it's growing, then look in the 
> > code for where a READU isn't released by a WRITE or RELEASE.
> >
> > Of course, as a vipassana meditator, I'd love to come over and show
> > you how to troubleshoot this... ;)
> >
> > "Our greatest duty in this life is to help others. And please, if 
> > you
> > can't help them, could you at least not hurt them?" - H.H. the Dalai 
> > Lama
> >
> > "When buying & selling are controlled by legislation, the first 
> > thing
> > to be bought & sold are the legislators" - P.J. O'Rourke
> >
> > Dan Fitzgerald
> > -------
> > u2-users mailing list
> > [EMAIL PROTECTED]
> > To unsubscribe please visit http://listserver.u2ug.org/
> -------
> u2-users mailing list
> [EMAIL PROTECTED]
> To unsubscribe please visit http://listserver.u2ug.org/
> 
> 
DISCLAIMER:-
<<This email is confidential and intended only for the use of the individual
or entity named above and may contain information that is privileged. If you
are not the intended recipient, you are notified that any dissemination,
distribution or copying of this email is strictly prohibited. If you have
received this email in error, please notify us immediately by return email
or telephone and destroy the original message.  Thank you.>>
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[EMAIL PROTECTED]
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to