<quote who="Womack, Adrian"> > Karl, > > Is that a UniData thing? Because with UniVerse exactly the reverse would > be true - writing to a sequential file (via CRT statements to a COMO or > with WRITESEQ to a record in a directory) would be much more efficient > and use less memory than performing a WRITEV (which has to read the > entire record in to memory so it can replace the field and then writes > the entire record out again), and that's without your overhead of > reading the record in the first place to simply count how many lines it > has.
When you do a WRITESEQ, if I understand the process, the OS has to read the entire record to determine the end of data at which point to append the next write. The method I propose would read the whole record once, then count the number of lines, set a variable with that total, then do a TTL += 1 for each subsequent write, eliminating the need to 'keep' the record in memory. For each WRITESEQ, the entire record is handled by the OS again, right? I know that on most OSes that's not necessarilly the case as there is a pointer to the exact location on the affected platter, but I'm not convinced that's the case here. > > I'd be surprised if the size of the &PH& record has anything to do with > the problem. Under normal circumstances, and without the observed functionality, I would agree... In any case, perhaps a test scenario could be created using both procedures. that way it could be demonstrated which affected the process more. I wouldn't be surprised to see them both fail at a measurable memory level... I wonder if it could be a weak, or failing, memory chip that's causing the problem. Karl > > AdrianW > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Wednesday, 11 October 2006 12:48 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] [UD] Weird Logging Issue > > I suspect you are right, but consider that you are writing to a > sequential file when you use the &PH& file as a 'log' file. Handling > that much data in an ongoing process will fill up the memory space > assigned to the phantom process. At least that's my story... > > I would recommend actually opening up an item in a file, counting the > number of lines in the file (with a routine to delete the top of the > file as it grows beyond a useful size) and then doing: > > WRITEV DATALINE on FILE,"LOGNAME",NEWLINE# THEN/ELSE . . . > > That way, you have very little user space memory wasted and can control > the log file size. > > HTH, > > Karl > > > DISCLAIMER: > Disclaimer. This e-mail is private and confidential. If you are not the > intended recipient, please advise us by return e-mail immediately, and > delete the e-mail and any attachments without using or disclosing the > contents in any way. The views expressed in this e-mail are those of the > author, and do not represent those of this company unless this is clearly > indicated. You should scan this e-mail and any attachments for viruses. > This company accepts no liability for any direct or indirect damage or > loss resulting from the use of any attachments to this e-mail. > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > -- karl _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson [EMAIL PROTECTED] -- IT Director, ATS Industrial Supply, Inc. http://www.atsindustrial.com Toll-free: 800-789-9300 x29 Direct2Desk: 801-978-4429 Facsimile: 801-972-3888 -- ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
