Mark Johnson wrote: > In 1978 ... I recall him reviewing a FOR...NEXT loop that had the FOR part in one > frame and the NEXT part in another and he was spending time trying to > put compilable code (not comments) in front of the FOR section in the > hope that the both the FOR and NEXT were in the same frame. This may > have had the moniker "Frame Faulting". Mainframes called this a Core > Dump.
I'm not sure how much the following applies to U2 environments anymore but I'd be interested if someone compared the info below to how U2 works now and in the past. The term Frame Faulting refers to the process where the DBMS is scanning for data and it encounters an end of frame before the end of the data it needs. So it looks at the frame forward link, performs a frame read, attaches the resulting data to the buffer in memory, then it goes back to scanning. It's a time consuming process that is best avoided where possible, and that's why we all fight so hard to keep data out of overflow. Pursuant to this discussion, if you have a Mod 1 file and need to constantly frame fault just looking for item IDs, you're putting an unnecessary burden on the environment. Doesn't the same thing happen when the Mod is larger? No and yes. Data is physically read from disk in chunks. Over the years the frame size in MV environments has closely followed the physical disk read size (an even disk sector in most cases), which is why we've seen an evolution from 512 to 1024, 2048, etc. Disk drives (and utilization of memory cache and intelligent read-ahead software) are always far ahead of MV, and in a single read they'll read an entire track of several contiguous sectors (contiguous frames) so that the next sequential frames (primary frame of the next group) has probably already been read into memory by the time the database decides that it has finished with one group and it needs the next one. These days that technology is so far ahead of MV that selective placement of data on disk just isn't worth the time. There is so much data in memory, and disk drives allocate and reallocate data based on errors detected and many other factors - we can't predict like we used to exactly where the heads are going to find our data. > Perhaps his age at the time (50?) indicated a respect for the > incredibly precious resources that he was used to and the disciplines > that he had to adhere to. In the last 28 years of my MV programming I > have never recalled having to be so anal as to perform such a > lower-level observation for such an unmeasurable improvement. Just for reference, back in the 80's I also used to do that sort of thing on R83, GA, Microdata, Ultimate, and maybe ADDS or other platforms. But when Pick started running on a host OS, all bets were off as some other kernel or hardware disk controller was now in control of disk access. The requirement for doing this was less for performance and more because from one release to the next, the DBMS environments would have problems frame faulting for object code, procs, MD entries, etc.. Tony TG@ removethisNebula-RnD.com ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
