For what it is worth: Glad to hear that someone else mostly uses dynamic files. There seems to be a bit of prejudice against them by ex-Pickers, (and a prejudice for them from on PI'ers like me!)
I never resize them. On the one hand, they are probably a little slower in the worst case, but they should never be a lot slower, as a statically hashed file can be if it is overloaded. Dynamic files are a bit more susceptible to problems after a system crash, but even that should not be a big problem for a log file. Depending on the volume of logging information, I would suggest the following: Create the file with a MINIMUM.MODULUS option that is 130% of your estimated data / 2000. This will pre-allocate space and give you performance approximating a statically hashed file (slower SELECTS than a new, empty dynamic file too). Before the first time you purge the file, consider using CONFIGURE.FILE to reset the MIMIMUM.MODULUS to the current mod prior to the purge. You are going to reuse that space anyway, so reconfiguring it to not shrink will speed up the purge and future adds. (rhetorically) Doesn't this make it just like a statically hashed file? Sort of, there are internal differences that handle large records better, and you are protected from the bane of an undersized static file. Also, consider using a timestamp instead of a sequential id. Why pound on that "&NEXT.AVAILABLE&" record when you are going to need a date and time anyway. There are options in the SYSTEM() function to get the GMT epoch value and Milliseconds. Just increment the milliseconds until you can lock a new record in the file. You will need to do this as a separate value from the GMT seconds, due to numerical accuracy. -Rick -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Wjhonson Sent: Tuesday, July 09, 2013 10:10 AM To: [email protected] Subject: Re: [U2] File type 30 (dynamic) Your mileage may vary, but almost *all* of our files are type 30's. Some of them grow and are purged annually as you suggest, for example G/L related files. *And* we have never.... resized them. Not ever. Never. I don't really know why they never need to be resized, some of them have 100,000 records, some have 1000. Maybe they should be resized, maybe it's not efficient. All I know is we never do it. -----Original Message----- From: Scott Zachary <[email protected]> To: u2-users <[email protected]> Sent: Tue, Jul 9, 2013 9:15 am Subject: [U2] File type 30 (dynamic) I have very little experience with using dynamic (type 30) files and I'm looking for some pointers in that regard. I have a file that I am considering creating as a dynamic file. The file will be a log file with sequential numeric keys. The record size will normally range from about 200 to 700 bytes, with a probable maximum size of less than 1,000 bytes. We expect the file to continually grow without deletions and we will likely purge it annually. What are the pro's and con's of creating this file as type 30 verses other file types? Thanks, Scott Zachary UniVerse Developer Gardens Alive! Inc -- View this message in context: http://u2-universe-unidata.1073795.n5.nabble.com/File-type-30-dynamic-tp41129.html Sent from the U2 - Users mailing list archive at Nabble.com. _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
