Chuck, We do exactly that in Jbase (also did it in UV). It is especially useful in EOD/EOM processing. We have our product files distributed by our 25 stores. We've found that you need to limit the select phantoms to a smaller number of concurrent processes. With our present configuration (4 CPUs), 5 is about right. The code is embedded in the main programs, but could easily be split out into free-standing utilities. We use the lists separately since access to a part file is faster than accessing the whole distributed file. We also have a merge-lists utility that could be used. All that being said, I'd be very cautious in using this method during the day - the users know where to find you, and they carry big sticks! ;^) Regards, Charlie Noah [EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) writes:
Has anyone written a utility to split out selects for distributed files, 1 phantom for each partfile, then pin the results into 1 select or saved list? The purpose would be to decrease total elapsed time for a given select on the big type30 file. Was it worth it? In pseudo-code, something like: get Selection-Criteria for partno = 1 to number of part-files phantom: SELECT partfile_partno [Selection-Criteria]; savelist [tempname]-[partno] next partno wait for all phantoms to finish merge all savedlists into active select list You get the idea. It could be implemented as verbs, SELDISTRIB & SSELDISTRIB. Or even just intercept SELECT and SSELECT, but simply executing the real thing if it finds the file is not distributed. Of course, the same amount of data needs to be traversed and digested, so this actually (slightly) increases total consumption of system resources due to the additional overhead. Possible i/o & even cpu contention. What was your experience? Thank-you for the sage advice, Chuck Stevenson ------- 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/
