Re: [U2] [UD] Weird Logging Issue
This is how append to Log files in UV: some of the log files get to be many hundreds of megabytes and this is still fast: % - subroutine APPEND.UNIX(NEW.LINE, PATH, ERR) ERR = '' ;* Return this if nothing goes wrong openseq PATH to SEQFILE else null ;* This does not fail if it's not there... * But this DOES fail if it's not there: status STAT from SEQFILE else ;* CREATE IT if it's not there... * Use WEOFSEQ to create it: weofseq SEQFILE on error ERR = 'Unable to WEOFSEQ ':PATH return end end OFFSET = 0 ;* No offset RELTO = 2 ;* Relative to the end of the file seek SEQFILE, OFFSET, RELTO else ERR = 'Unable to SEEK on ':PATH return end * We could also write binary data this way ?: * WRITEBLK CONTENTS TO SEQFILE ELSE writeseqf NEW.LINE to SEQFILE else ERR = 'Unable to WRITESEQF on ':PATH return end closeseq SEQFILE ( I subscribe only to the digest so 'cc' me on any replies ? ...) - JimA --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Weird Logging Issue
Also, could you confirm that your VOC _PH_ is in fact a DIR-type? Yes sir, it is a DIR-type file. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com ** Check out scheduled Connect! training courses at http://www.PrecisOnline.com/train.html. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Weird Logging Issue
Adrian, normally I would agree with you, sequential file output SHOULD be more efficient. However, because this isn't your typical WRITESEQ type situation - the output is coming from PRINT statements - my theory is that the rules may be different. And if I hadn't seen this thing get wacky at 2.8M, 3.1M, etc., and then magically become perfect after a restart of the phantom I would certainly be considering other ghosts. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com ** Check out scheduled Connect! training courses at http://www.PrecisOnline.com/train.html. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Weird Logging Issue
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/
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 quote who=Kevin King I am supporting a phantom program that uses PRINTs to output information to _PH_ for a log. When this log starts getting near 3MB, the phantom begins performing very strange. For example, sometimes a READ in the phantom will be successful, but the variable that was read is null (even though the record itself is intact). It seems like a memory issue as restarting the phantom (and getting a new log) seems to clear everything up. Does anyone have any experience to support or discredit this theory? -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com http://www.precisonline.com/ ** Check out scheduled Connect! training courses at http://www.precisonline.com/train.html http://www.PrecisOnline.com/train.html. --- 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/
RE: [U2] [UD] Weird Logging Issue
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: I'd love to implement more elegant logging, but as this is a vendor-written process, my options are a bit limited at the time. I need to prove the point before I can recommend anything that could change the way the vendor designed this particular process. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com ** Check out scheduled Connect! training courses at http://www.PrecisOnline.com/train.html. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Weird Logging Issue
I've seen similar erratic behavior when a phantom process set locks for a possible update, but then didn't clear the lock when no update occurred. I'm suggesting you have a locking issue but the out of memory behavior is identical - it waits for available memory before it can perform the next read. In our case the lock table was consuming the memory - with yours something else is consuming and not releasing the memory. HTH -Baker quote who=Kevin King I am supporting a phantom program that uses PRINTs to output information to _PH_ for a log. When this log starts getting near 3MB, the phantom begins performing very strange. For example, sometimes a READ in the phantom will be successful, but the variable that was read is null (even though the record itself is intact). It seems like a memory issue as restarting the phantom (and getting a new log) seems to clear everything up. Does anyone have any experience to support or discredit this theory? -Kevin --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Weird Logging Issue
Corrected posting - sorry... I've seen similar erratic behavior when a phantom process set locks for a possible update, but then didn't clear the lock when no update occurred. I am NOT suggesting you have a locking issue but the out of memory behavior is identical - it waits for available memory before it can perform the next read. In our case the lock table was consuming the memory - with yours something else is consuming and not releasing the memory. HTH -Baker quote who=Kevin King I am supporting a phantom program that uses PRINTs to output information to _PH_ for a log. When this log starts getting near 3MB, the phantom begins performing very strange. For example, sometimes a READ in the phantom will be successful, but the variable that was read is null (even though the record itself is intact). It seems like a memory issue as restarting the phantom (and getting a new log) seems to clear everything up. Does anyone have any experience to support or discredit this theory? -Kevin --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UD] Weird Logging Issue
Hi Kevin, What O/S? _PH_ is a DIR-type file, so your issue could be O/S-related. Also, could you confirm that your VOC _PH_ is in fact a DIR-type? If a record reaches 3MB in a hashed file, every multivalued database I've worked with gets cranky. Hope this helps, Tom [EMAIL PROTECTED] 10/10/06 11:59 AM I am supporting a phantom program that uses PRINTs to output information to _PH_ for a log. When this log starts getting near 3MB, the phantom begins performing very strange. For example, sometimes a READ in the phantom will be successful, but the variable that was read is null (even though the record itself is intact). It seems like a memory issue as restarting the phantom (and getting a new log) seems to clear everything up. Does anyone have any experience to support or discredit this theory? -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com http://www.precisonline.com/ ** Check out scheduled Connect! training courses at http://www.precisonline.com/train.html http://www.PrecisOnline.com/train.html. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ - This e-mail and any attachments may contain CONFIDENTIAL information, including PROTECTED HEALTH INFORMATION. If you are not the intended recipient, any use or disclosure of this information is STRICTLY PROHIBITED; you are requested to delete this e-mail and any attachments, notify the sender immediately, and notify the LabCorp Privacy Officer at [EMAIL PROTECTED] or call (877) 23-HIPAA / (877) 234-4722. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UD] Weird Logging Issue
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. I'd be surprised if the size of the PH record has anything to do with the problem. 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/
