I would not envision having every active UniData process on the system close all of their files when a dbpause command is run. Each process has it's own file handles in its private memory.
Processes not actively updating files would need to be signaled that dbpause is requested and then run through their file table and issue close commands at the OS level - then let the dbpause process know they are done. Also - a UniBasic process that issues a WRITE command and detects dbpause is active will just wait until dbresume. If the process were to close their files, it would have to 'jump out' of the WRITE, cycle thru closing all files, and then resume context of the WRITE statement. All of this seems overly intensive and possibly not easily architected. Just providing some background (and my bias). Regards, Wally Terhune Technical Support Engineer Rocket Software 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA t: +1 720 475 8055 **e: [email protected] **w: rocketsoftware.com/u2 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Wolverton Sent: Thursday, August 09, 2012 9:06 AM To: 'U2 Users List' Subject: Re: [U2] dbpause/dbresume or stopud/startud WELL... in theory UniData has SOME control -- I mean, on Windows, there could be a dbpause 'flag' that tells UniData to close all the open file handles on dbpause and reopen them on dbresume. That would fix the issue! _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
